(j3.2006) Fw: (j3-members.2015) Question about DO CONCURRENT
Daniel C Chen
cdchen
Tue Feb 10 17:49:24 EST 2015
Yes. BLOCK works if users use it.
I guess what I want to confirm is if Malcolm's example as it is (without
BLOCK) is standard conforming.
If it is not, the standard doesn't seem have explicit restrictions to
disallow it.
If it is conforming, it doesn't seem have a well defined behavior by the
current wording as well.
Thanks,
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
From: Bill Long <longb at cray.com>
To: Van Snyder <Van.Snyder at jpl.nasa.gov>, fortran standards email
list for J3 <j3 at mailman.j3-fortran.org>
Date: 02/10/2015 16:37
Subject: Re: (j3.2006) Fw: (j3-members.2015) Question about DO
CONCURRENT
Sent by: j3-bounces at mailman.j3-fortran.org
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
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20150210/446b9190/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://mailman.j3-fortran.org/pipermail/j3/attachments/20150210/446b9190/attachment-0001.gif
More information about the J3
mailing list