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

Malcolm Cohen malcolm
Mon Feb 9 19:34:18 EST 2015

I wrote:
>      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.

................................Malcolm Cohen, Nihon NAG, Tokyo. 

More information about the J3 mailing list