[J3] Question not just for HPC

[John Reid]

Hi,

Malcolm Cohen via J3 wrote:
> Hi folks,
> 
> The following program:
> 
> Program co428
> 
>    Use Iso_Fortran_Env
> 
>    Type(lock_type),Target :: p[*]
> 
>    Type lockpointer
> 
>      Type(lock_type),Pointer :: q
> 
>    End Type
> 
>    Type(lockpointer) x
> 
>    x%q => p
> 
>    Lock(x%q)
> 
>    Print *,'Is this really ok?'
> 
> End Program
> 
> is rejected by several compilers, usually with obviously-bogus messages, 
> like claiming that a pointer assignment is a variable definition context 
> (it is not).

I don't understand this. Item (3) in 16.6.7 seems to say that a pointer 
assignment is a variable definition context.

Note that C1303 in 13.8.2.16 says
"A lock variable shall not appear in a variable definition context 
except as the lock-variable in a LOCK or UNLOCK statement, as an 
allocate-object, or as an actual argument in a reference to a procedure 
with an explicit interface where the corresponding dummy argument has 
INTENT (INOUT)."

The statement x%q => p is changing the value of the lock variable x%q, 
in contradiction at least to the spirit of C1303.

Cheers,

John.





> 
> I note that:
> 
>  1. Type lockpointer does not have a potential subobject component of
>     lock_type.
>  2. That means X does not have to be a coarray.
>  3. In the LOCK statement, the lock variable is not a coarray (though it
>     is pointer-associated with a coarray).
>  4. Compiler opinions to the contrary, I can find no reason to say this
>     program is not conforming. It’s possible that I’ve missed something.
> 
> Being able to lock and unlock local coarrays via a pointer is not very 
> exciting, but it is not nothing.
> 
> Have I missed something that would make this program invalid according 
> to our current standard? Please let me know where to find the rule if so.
> 
> Anyway, assuming that I didn’t miss a rule making this invalid, I am not 
> raising an interp request at this time (I have a long list of other 
> things wrong with coarrays that I must get around to making interps 
> for!). However I am interested in hearing opinions as to whether this is 
> an “obvious defect in the standard”, or an “obvious compiler bug”. 
> Reasonings or motivation for the first opinion please (if the program 
> really is valid by the current standard, that is a good enough reason to 
> call it a compiler bug).
> 
> Cheers,
> 
> -- 
> 
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
>