(j3.2006) Integration of co-arrays with the intrinsic shift functions

[Malcolm Cohen]

On Thu, 19 Jul 2007 04:25:52 +0900, <dick.hendrickson at att.net> wrote:
> It's worse if the expression is something like
>
>     X = f(b) + g(c)
>
> and the syncs happen in f and g.  If every image is compiled with the  
> same compiler, it doesn't matter because everything will be in the same  
> (unspecified) order.  If different images are compiled by different  
> compilers, then they'll have to agree on expression evaluation odder.  I  
> think that's surprising.

Right, and this means that the argument about whether the CO_whatever is a  
function
or a subroutine could be somewhat moot.

And you say "same compiler ... doesn't matter".  But it's worse than that.
Evaluation order can be affected by compilation options,
in particular optimisation options.

So everything needs to be compiled with the same compiler with the same  
options.
This is getting pretty close to "the same executable".

The underlying mechanism/protocols of coarray handling are not  
standardised.
It seems unlikely that different vendors will all choose the same mechanism
with the same protocols - it's more likely that they'll all keep them as
trade secrets unless patented.

BTW, we've slightly acknowledged the problems in 7.1.7 where we say
   "If a statement contains a function reference in a part of an expression
    that need not be evaluated, no invocation of that function in that part
    of the expression shall execute an image control statement other than
    CRITICAL or END CRITICAL."

(a) Obviously this doesn't even attempt to tackle the ordering question.

(b) I find the wording quite confusing.

(c) I doubt that whether the expression part "needs" to be evaluated is
     the right distinction.

(d) Maybe it is apparently already caught for the whole expression by
     "The evaluation of a function reference shall neither affect nor be
      affected by the evaluation of any other entity within the statement."
     (7.1.4).  People (well Aleks anyway) seem to believe that  
synchronisation
     counts as a side-effect.  So it seems pretty clear that synchronisation
     is "affecting" the evaluation of anything else that is being  
synchronised.
     In particular, deadlock is obviously an effect.

     Actually, the quoted text in 7.1.4 could be interpreted as ruling out
     the same CRITICAL section being used by more than one function in an
     expression.  (Even if it doesn't, it rules out all useful CRITICAL
     sections being used by more than one function!)

Cheers,
-- 
Malcolm Cohen, Nihon Numerical Algorithms Group KK, Tokyo, Japan.