[J3] Question not just for HPC

[Bill Long]

> On Oct 16, 2019, at 1:13 AM, Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org> 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 note that:
> 	• Type lockpointer does not have a potential subobject component of lock_type.

Type locktype has a component of type lock_type (obviously).  A subobject is just a part of an object that can be referenced (3.141), so the component is clearly a subobject of x.  So, could you explain how the word “potential” makes the statement above true? 

> 	• That means X does not have to be a coarray.
> 	• In the LOCK statement, the lock variable is not a coarray (though it is pointer-associated with a coarray).

Having something pointer associated with a coarray does not make the pointer itself a coarray.  Only being declared to be a coarray (having a codimension) makes something a coarray. 

Cheers,
Bill


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

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray, a Hewlett Packard Enterprise company/ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425