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

[Bill Long]

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?

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