[Bug fortran/109575] New: Implement runtime check for valid function result

[Bug fortran/109575] New: Implement runtime check for valid function result

[anlauf at gcc dot gnu.org]

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

            Bug ID: 109575
           Summary: Implement runtime check for valid function result
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: anlauf at gcc dot gnu.org
  Target Milestone: ---

Split off from the discussion in pr109500: consider

program main
  implicit none
  integer, allocatable  :: p
  p = f()          ! <- this assignment may fail
  print *, allocated (p)
contains
  function f()
    integer, allocatable :: f
    allocate (f, source=42)
    deallocate (f) ! <- this renders the function invalid
  end function
end

This code is invalid as the function result must be defined:

F2018:15.6.2.2

On completion of execution of the function, the value returned is that
of its function result. If the function result is a data pointer, the
shape of the value returned by the function is determined by the shape
of the function result when the execution of the function is completed.
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.


A runtime check that can detect the failing assignment needs to check
that the function result is defined when the function returns.

[Bug fortran/109575] Implement runtime check for valid function result

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-04-20
           Priority|P3                          |P4

--- Comment #1 from kargl at gcc dot gnu.org ---
Change status to "new" as I agree with Harald that this would be a nice runtime
warning for debugging.

Changed to 'P4'

[Bug fortran/109575] Implement runtime check for valid function result

[anlauf at gcc dot gnu.org]

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
I have some idea how (and where) the runtime checks need to be implemented,
but I am confused by the following observations on the occurence of an
explicit RETURN statement and the use of a RESULT variable:

function f()
  integer :: f
end

function f1()
  integer :: f1
  f1 = 1
end

function q() result (f)
  integer :: f
end

function q2() result (f)
  integer :: f
  f = 2
end

function g()
  integer :: g
  return
end

function g3()
  integer :: g3
  g3 = 3
  return
end

function r() result (f)
  integer :: f
  return
end

function r4() result (f)
  integer :: f
  f = 4
  return
end

While the dump-fortran-original does not show any surprises, the tree-dump
looks somewhat irregular:

__attribute__((fn spec (". ")))
integer(kind=4) f ()
{
  (void) 0;
}


__attribute__((fn spec (". ")))
integer(kind=4) f1 ()
{
  integer(kind=4) __result_f1;

  __result_f1 = 1;
  return __result_f1;
}


__attribute__((fn spec (". ")))
integer(kind=4) q ()
{
  (void) 0;
}


__attribute__((fn spec (". ")))
integer(kind=4) q2 ()
{
  integer(kind=4) f;

  f = 2;
  return f;
}


__attribute__((fn spec (". ")))
integer(kind=4) g ()
{
  integer(kind=4) __result_g;

  return __result_g;
  return __result_g;
}


__attribute__((fn spec (". ")))
integer(kind=4) g3 ()
{
  integer(kind=4) __result_g3;

  __result_g3 = 3;
  return __result_g3;
  return __result_g3;
}


__attribute__((fn spec (". ")))
integer(kind=4) r ()
{
  return;
}


__attribute__((fn spec (". ")))
integer(kind=4) r4 ()
{
  integer(kind=4) f;

  f = 4;
  return f;
  return f;
}


This seems to correspond to two different paths to gfc_generate_return().

[Bug fortran/109575] Implement runtime check for valid function result

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Fri, Apr 21, 2023 at 08:24:45PM +0000, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109575
> 
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> I have some idea how (and where) the runtime checks need to be implemented,
> but I am confused by the following observations on the occurence of an
> explicit RETURN statement and the use of a RESULT variable:
> 
> __attribute__((fn spec (". ")))
> integer(kind=4) q2 ()
> {
>   integer(kind=4) f;
> 
>   f = 2;
>   return f;
> }
> 
> 
> __attribute__((fn spec (". ")))
> integer(kind=4) g ()
> {
>   integer(kind=4) __result_g;
> 
>   return __result_g;
>   return __result_g;
> }
> 

So, if I follow you correctly, you're worried by about
the two 'return __result_g' versus the one 'return f'?
Dead code elimination likely removes the second 
'return __result_g'.  It indeed seems odd!