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

["kargl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #18 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #17)
> (In reply to Steve Kargl from comment #16)
> > First, note, 'allocated(f())' throws an error.
> 
> Agree.
> 
> > 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.
> 
> Agree.  See also the discussion on the J3 mailing list.
> 
> > 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.
> 
> Agree.
> 
> > 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.
> 
> Agree again.
> 
> The point is that there is a bug in gfortran which currently effectively
> generates code which resembles
> 
>   integer, allocatable :: p
>   p = f()
>   print *, is_allocated(p)
>   deallocate (p)
> 
> (of course with a temporary for the function result).
> The technical reason for the crash is the copying of the function
> (non)result.
> 
> The patch in comment#9 rejects all related misuses.
> 
> Given the lengthy thread on the J3 mailing list, I am wondering whether there
> ever was an explicit IR on the issue, or was it considered so obvious that
> the clarification was deferred to the F2018 document.
> 
> 
> 
> > 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.

I think we agree on all points.  Here's the diff I envision.
NOte, I've restricted it to user defined functions.  Remove 
the esym check will enable it for any subprogram.


diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index db79b104dc2..f3bcdd76d6a 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -3622,6 +3622,18 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap,
gfc_formal_arglist *formal,
          goto match;
        }

+      if (a->expr->expr_type == EXPR_FUNCTION
+         && a->expr->value.function.esym
+         && f->sym->attr.allocatable)
+       {
+         if (where)
+           gfc_error ("Actual argument for %qs at %L is a function result "
+                       "and the dummy argument is ALLOCATABLE",
+                       f->sym->name, &a->expr->where);
+         ok = false;
+         goto match;
+       }
+
       /* Check intent = OUT/INOUT for definable actual argument.  */
       if (!in_statement_function
          && (f->sym->attr.intent == INTENT_OUT

This gives

% gfcx -c a.f90
a.f90:5:25:

    5 |    print *, is_allocated(f())
      |                         1
Error: Actual argument for 'p' at (1) is a function result and the dummy
argument is ALLOCATABLE