https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125606
Harald Anlauf <anlauf at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |anlauf at gcc dot gnu.org
--- Comment #13 from Harald Anlauf <anlauf at gcc dot gnu.org> ---
(In reply to Steve Kargl from comment #12)
> Hmmm, that's an interesting question. If the code was previously
> accepted, POLA would suggest that we need to "fix" the issue.
POLA?
> The documentation for LOC simply states that "‘LOC(X)’ returns the
> address of X as an integer."
>
> C_LOC is much more strict than LOC. The variable
> "shall have the POINTER or target ATTRIBUTE"
> and
> "shall be a variable with interoperable type and kind type parameters"
> The code meets neither requirement.
It is trivial to add TARGET, but the lack of interoperability prevents
using C_LOC. NAG would reject it with
Error: pr125606.f90, line 21: The argument to C_LOC must not be polymorphic
...
> I don't know enough about gfortran's implementation details for CLASS(*)
> so don't know how, or if, we can unwind the levels on indirection from
> the associations.
The user gets what he/she asks for...
> PS: your potential fix appeared while I was writing the above.
It looks somewhat artificial, but seems to do the job. But I am not
entirely sure if this is the correct approach, as I now found:
F2023:11.1.3.3 Other attributes of associate names
(4) ... The associating entity is contiguous if and only if the selector is
contiguous.
So do we have a temporary with SELECT TYPE or not?
