(j3.2006) (SC22WG5.3653) [ukfortran] FW: Notes on WG5 coarray papers

[Reinhold Bader]

Hello Malcolm,

Malcolm Cohen schrieb:
> I have a couple of obvious comments...
> 
[discussion on restriction I want but cannot get]

Do you think this is then only a matter of telling users
"don't use volatile (array, derived type) coarrays thusly" or
something which needs fixing in the standard in a more
appropriate manner than suggested by me?

> 
>> Example 2.4 ("Protected Context") is non-conforming since the cited
>> restriction is violated by the object in question being VOLATILE within
>> the scope of the DO loop. This would apply even if the CASE(1) statements
>> were not present.
>>   
> There is no restriction that says a DO index variable cannot have the 
> VOLATILE attribute, and the "cited restriction" does not even mention 
> VOLATILE.  So I cannot agree with your reasoning.  (In fact I think the 
> example is conforming when used as described in the paper.)

I don't agree with that one. Referring to 08-007r2, we have

5.3.19 para1: The VOLATILE attribute specifies that an object may be referenced,
                       defined, or become undefined, by means not specified by the program,
                       or by another image without synchronization.

so if the DO index variable is volatile, it will by virtue of its volatility violate the cited
restriction, won't it? Or do you consider the program conforming (statistically
conforming?) as long as simply by chance the index isn't stomped on by anyone
else while DO executes?

>> In section 4 ("Behaviour on Commodity Clusters"), the example with the
>> INTEGER, VOLATILE :: table(1000)[*]
>> has a high likelihood of being non-conforming since again the object is
>> not scalar, and there may be updates coming in from other images in an
>> unordered segment.
> Au contraire, there are no references to the array table in the example 
> code, only to scalar subobjects thereof.  Scalar subobjects of a 
> VOLATILE object are themselves VOLATILE.  And scalar.  And thus don't 
> even fall foul of the imaginary restriction that is not yet in 8.5.1.

Nicely put :-)

> 
> Cheers,

Best Regards

Reinhold