https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92122
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|rejects-valid |ice-on-valid-code
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Bill wrote to J3:
> > • 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?"
>
> > • 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.
I concur.
Hence, that makes the code in comment 0 invalid – threre is still the issue
with the __tmp_type_… name which leaks through.
Additionally, motivated by the second code in comment 0, I wrote the following
program (four). It and the simplified 'three' resolve but then give an ICE at
0x5d9c7c convert(tree_node*, tree_node*)
../../repos/gcc/gcc/fortran/convert.c:119
0x969fba trans_associate_var
../../repos/gcc/gcc/fortran/trans-stmt.c:2139
! ---------- three --------
class(*), allocatable :: q[:]
allocate(integer :: q[*])
select type (q)
type is (integer)
q[1] = 5
end select
end
! ---------- four --------
use, intrinsic :: iso_fortran_env, only : lock_type
class(*), allocatable :: q[:]
allocate(lock_type :: q[*])
select type (q)
type is (lock_type)
lock(q)
end select
end
