[J3] Question not just for HPC
parekhvs at gmail.com
Wed Oct 16 07:35:51 EDT 2019
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
type(lock_type), target :: p[*]
type(lock_t) :: x
x%q => p
select type ( q => x%q )
type is ( lock_type )
lock( q )
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.
More information about the J3