https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106692
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Sure, in the middle-end the assumption that REFERENCE_TYPE vars/parameters may
never bind to NULL are correct.
I'd say this is just a user error, but am not a Fortran language lawyer.
It is hard to argue about Cray pointers when they aren't part of the official
Fortran standard, but let's just use some wording about real Fortran POINTERs.
zz1 is a normal dummy argument (real :: zz1).
E.g. in J3/97-007R2, 12.4.1.1 says:
"If the dummy argument is not a pointer and the corresponding actual argument
is a pointer, the actual argument shall be currently associated with a target
and the dummy argument becomes argument associated with that target."
so, for POINTERs passed as actual arguments to normal non-pointer dummy
arguments they have to be associated (aka not NULL), rather than disassociated
(aka NULL) or undefined (aka uninitialized).
I'd say it is the same thing with Cray pointers even when it doesn't give those
special names, but passing a Cray pointee where the associated Cray pointer is
uninitialized or pointing to absolute address where no object is present to a
function that expects something it can access looks undefined behavior.
If zz1 had the VALUE attribute, it would always crash already during the
passing, like it would to just do zz1 = 0 in test_cray. As it doesn't have
VALUE attribute in the testcase, it would also crash if shape_cray did whatever
= zz1 or zz1 = 0 etc.
I think one needs to use OPTIONAL if an argument might not be passed at all, or
POINTER/ALLOCATABLE if a dummy argument is to be sometimes associated/allocated
and sometimes is not, or make the dummy argument a Cray pointer.
That would be subroutine shape_cray(ptrzz) and dropping the ptrzz=loc(zz1)
line,
and on the caller side call shape_cray(ptrzz1).
Changing component to fortran, so that the Fortran maintainers can voice in.
If it would be a compiler bug, it would be a FE bug, where it couldn't use
REFERENCE_TYPE on types of objects that could through Cray pointers bind to
NULL
(perhaps with -fcray-pointers only).
