[J3] Question not just for HPC

[Vipul Parekh]

Hello Malcolm,

The code appears conforming to me.

A compiler I tried, Intel Fortran version 19.0 Update 5, has only 2
issues with the code you post: 1) that x is not a coarray and 2) that
x%p => q is a variable definition context,  You explain, correctly in
my opinion, how both these complaints are bogus.  So what's left then
are compiler bugs that lead to its 2 complaints.

Said compiler processes the following code without complaints:

   use, intrinsic :: iso_fortran_env, only : lock_type

   type :: lock_t
       class(*), pointer :: q
   end type
   type(lock_type), target :: p[*]
   type(lock_t) :: x

   x%q => p
   select type ( q => x%q )
      type is ( lock_type )
         lock( q )
   end select

end

The main difference with the modification being the component 'q' that
is unlimited polymorphic.  Perhaps I'm totally wrong about this, but
this variant appears equivalent to me to the example you show as far
as the constraints C1608 and C1609 with LOCK_TYPE are concerned which
trip up the compiler with your code.

Your use of 'type(lock_type), pointer :: q' in your derived type is a
good 'visual aid' for a reader to signal the intent but otherwise
there's nothing to trouble a compiler given the definitions of
'potential subobject component' as well as 'variable definition
context' in the standard.  Hence my conclusion it's a compiler bug.

Hope this is of some help.

Regards,
Vipul Parekh