[J3] Question not just for HPC
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
> 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 220.127.116.11 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
> 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).
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
More information about the J3