[Bug fortran/109500] SIGABRT when calling a function that returns an unallocated value

["sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500

--- Comment #16 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Apr 19, 2023 at 07:15:50PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
> 
> --- Comment #15 from anlauf at gcc dot gnu.org ---
> (In reply to Steve Kargl from comment #13)
> > Note 1 in Fortran 2023, Sec. 8.5.3, p. 100, is non-normative
> > text.  I suppose one can claim that gfortran should throw an
> > error when a function result is marked with the allocatable
> > attribute.
> 
> You mean when the function result is not allocated in that case?


First, note, 'allocated(f())' throws an error.

Error: 'array' argument of 'allocated' intrinsic at (1) must be a variable

You get this error regardless of the allocation status of the 
function result.

Now, with the original code,

      is_allocated(f())

The function reference is evaluated, and then the function result
(aka it's value) is argument associated with an allocatable dummy
argument.  This is technically wrong as the actual argument (aka
value returned by the function reference) should not have the
allocatable attribute.

   Fortran 2018

   15.5.2.6 Allocatable dummy variables

   The requirements in this subclause apply to actual arguments
   that correspond to allocatable dummy data objects.

   The actual argument shall be allocatable.  It is permissible
   for the actual argument to have an allocation status of
   unallocated.

I'll repeat.  The actual argument is the value resulting from
the function reference.  The "shall" in "shall be allocatable"
applies to something the programmer must ensure.


> > Unfortunately, it is likely a catch-22 situation
> > in that gfortran needs to know the function result is allocatable
> > so it can do the allocaton within the function, but it is not
> > an allocatable outside of the function.  Not sure gfortran
> > can mark an internal symbol to do both.
> 
> I checked how to implement a run-time check for a non-allocated
> function result, but did this in the wrong place - in the caller.
> This did work when I did allocate and the deallocate before return,
> otherwise the result variable is simply undefined, and the check does
> not work.
> 
> So a run-time check needs to be put where the function return is generated.
> 

If we go back to the original code and modify to allocate
f by say doing 'f = 42' in f(), gfortran produces 

% gfcx -o z -Wall a.f90 && ./z
 T

This is the problem.  Yes, f is allocated and assigned 
42.  The printed 'T' is bogus because 42 is value of
the function.  42 is no allocatable.

One place to possibly check for an error is when 
gfortran resolves argument association.  If a dummy
argument is allocatable, the actual argument needs 
to be allocatable and cannot not also be a function
result variable.