https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126517
--- Comment #3 from Steve Kargl <kargl at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #2)
> (In reply to Steve Kargl from comment #1)
> > I think the code is invalid.
> >
> > F2023: 15.6.2.2 Function subprogram:
> > ...
> > If the function result is not a pointer, its value shall be defined
> > by the function. If the function result is a pointer, on return the
> > pointer association status of the function result shall not be undefined.
> >
> > The first sentence above indicates that the function
> > result needs be defined, and only way that can happen is if
> > the function result variable is allocated.
>
> OK, makes sense. So allocatable functions can't return a nullified
> descriptor, whereas pointer functions can. I tested a similar example with
> pointers, and that one works as expected. So I'm closing this. Thanks for
> the feedback.
I would need to dig out an older standard. IIRC, in the old days an
allocatable entity could be undefined, unallocated, or allocated.
I think, but need to check, F18 decided such an entity could only be
unallocated or allocated, and removed the undefine-ness possibility.
The statement on page 149 of Fortran 2023 that may be relevant is
At the beginning of execution of a program, allocatable variables
are unallocated.
Pointers can be undefined, associated, or unassociated. F2023,
19.5.2.2 'Pointer association status' goes into gory detail about
pointers.
Your example suggests that gfortran should issue an error/warning
about an unallocated function result. Given the complexity of
the allocation/deallocation code, this may be a difficult thing to
get right.
