(j3.2006) Fw: (j3-members.2015) Question about DO CONCURRENT

Bill Long longb
Tue Feb 10 16:36:32 EST 2015


On Feb 10, 2015, at 3:29 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:

> On Tue, 2015-02-10 at 21:01 +0000, Bill Long wrote:
>> Looking back at old emails, we?ve been discussing this off and on for
>> about 10 years, including before F2008 was voted.   Is there a reason
>> why the BLOCK option does not work?
> 
> If this is a sufficiently frequent problem, could we add a
> <specification-part> directly to the DO CONCURRENT construct, with
> explicit explanation that the declared entities are private to each
> iteration?


Seems like feature creep.   I don?t think the issue is sufficiently common, and we already seem to have a solution.

> 
> Even if we don't do that, should we have at least a note to explain that
> objects declared in a BLOCK construct within a DO CONCURRENT construct
> are separately private to each iteration?


That would be OK with me.  It has zero additional implementation cost, and it could help avoid questions in the future.

Cheers,
Bill

> 
>> Cheers,
>> Bill
>> 
>> 
>> On Feb 10, 2015, at 2:24 PM, Daniel C Chen <cdchen at ca.ibm.com> wrote:
>> 
>>> Shall we allocate some time to talk about it on #206? Do we need a paper to initiate the discussion?
>>> 
>>> Thanks,
>>> 
>>> Daniel
>>> 
>>> XL Fortran Development - IBM Toronto Software Lab
>>> Phone: 905-413-3056   
>>> Tie: 969-3056   
>>> Email: cdchen at ca.ibm.com
>>> http://www.ibm.com/software/awdtools/fortran/xlfortran
>>> 
>>> <graycol.gif>"Malcolm Cohen" ---02/09/2015 19:34:30---I wrote: >    DO CONCURRENT(...)
>>> 
>>> From:	"Malcolm Cohen" <malcolm at nag-j.co.jp>
>>> To:	"fortran standards email list for J3" <j3 at mailman.j3-fortran.org>
>>> Date:	02/09/2015 19:34
>>> Subject:	Re: (j3.2006) Fw:  (j3-members.2015) Question about DO CONCURRENT
>>> Sent by:	j3-bounces at mailman.j3-fortran.org
>>> 
>>> 
>>> 
>>> I wrote:
>>>>   DO CONCURRENT(...)
>>>>     IF (condition) THEN
>>>>          X = something
>>>>          code using X
>>>>     END IF
>>>>     code that doesn't use X
>>>>  END DO
>>>> 
>>>> you cannot localise X, because if "condition" is true exactly once, the
>>>> assignment affects the "outer" X.  OTOH, if condition is true more than once,
>>>> you cannot execute in parallel without localising X.  Rather UGH."
>>> 
>>> Bill Long writes:
>>>> A ?solution? should not have the effect of making a currently 
>>>> standard-conforming program suddenly not conforming.
>>> 
>>> This was only introduced in the current standard.  Therefore it is fixable via 
>>> interp *IF* we agree that such cases should not be conforming.
>>> 
>>> Obviously there are various ways of rewriting the code.  "Option 2" works if the 
>>> compiler supports both DO CONCURRENT and BLOCK.  Changing the name of X to 
>>> something that appears nowhere else in the program unit also works.  Neither of 
>>> these are particularly likely to be favoured by many users.
>>> 
>>> Bill continues:
>>>> That would seem to disqualify option 2 below.
>>> 
>>> Not in itself, however, option 2 below is sadly unworkable anyway...
>>> 
>>> Daniel Chen suggested:
>>>> "A variable that is referenced in an iteration shall either be previously 
>>>> defined during that iteration, or shall not be defined or become undefined 
>>>> during any other iteration. A variable that is defined or becomes undefined by 
>>>> one or more iterations becomes undefined when the loop terminates. "  -- This 
>>>> will allow compiler to localised x in the above example.
>>> 
>>> Unfortunately that would mean the DO CONCURRENT loop cannot achieve anything 
>>> other than i/o.  Bathwater meet baby.
>>> 
>>> I don't see any obvious solution, at least without additional syntax, that is 
>>> better than telling the user "don't do that", unsatisfactory though it seems.
>>> 
>>> Cheers,
>>> -- 
>>> ................................Malcolm Cohen, Nihon NAG, Tokyo. 
>>> 
>>> _______________________________________________
>>> J3 mailing list
>>> J3 at mailman.j3-fortran.org
>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>> 
>>> _______________________________________________
>>> J3 mailing list
>>> J3 at mailman.j3-fortran.org
>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>> 
>> Bill Long                                                                       longb at cray.com
>> Fortran Technical Suport  &                                  voice:  651-605-9024
>> Bioinformatics Software Development                     fax:  651-605-9142
>> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
>> 
>> 
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101





More information about the J3 mailing list