[J3] Question not just for HPC

John Reid John.Reid at stfc.ac.uk
Wed Oct 16 07:24:14 EDT 2019


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 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 

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



> 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.

More information about the J3 mailing list