[Bug fortran/55603] New: Memory leak in intrinsic assignment of allocatable derived type function result

[Bug fortran/55603] New: Memory leak in intrinsic assignment of allocatable derived type function result

[damian at rouson dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603

             Bug #: 55603
           Summary: Memory leak in intrinsic assignment of allocatable
                    derived type function result
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: damian@rouson.net


valgrind reports a memory leak in the code below.  FY, this is a greatly
simplified version of the actual use case.  In the intended use case, the "bar"
procedure is type-bound and is invoked via a type-bound generic operator that
appears in a longer expression composed of various user-defined operators.

Damian


$ gfortran --version
GNU Fortran (MacPorts gcc48 4.8-20121202_0) 4.8.0 20121202 (experimental)

$ cat leak.f90
  type foo
  end type
  type(foo) a
  a = bar()
contains
  function bar()
    type(foo), allocatable :: bar
    allocate(bar)
  end function
end
$ gfortran leak.f90
$ valgrind ./a.out
==5151== Memcheck, a memory error detector
==5151== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==5151== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==5151== Command: ./a.out
==5151==
--5151-- ./a.out:
--5151-- dSYM directory is missing; consider using --dsymutil=yes
==5151==
==5151== HEAP SUMMARY:
==5151==     in use at exit: 1,998 bytes in 33 blocks
==5151==   total heap usage: 49 allocs, 16 frees, 5,706 bytes allocated
==5151==
==5151== LEAK SUMMARY:
==5151==    definitely lost: 1 bytes in 1 blocks
==5151==    indirectly lost: 0 bytes in 0 blocks
==5151==      possibly lost: 0 bytes in 0 blocks
==5151==    still reachable: 1,997 bytes in 32 blocks
==5151==         suppressed: 0 bytes in 0 blocks
==5151== Rerun with --leak-check=full to see details of leaked memory
==5151==
==5151== For counts of detected and suppressed errors, rerun with: -v
==5151== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[Bug fortran/55603] Memory leak in intrinsic assignment of allocatable derived type function result

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janus at gcc dot gnu.org

--- Comment #1 from janus at gcc dot gnu.org 2012-12-05 08:26:19 UTC ---
The problem seems to be that we fail to do auto-deallocation of the function
result (after the assignment). One should check the standard, if and where this
is actually demanded.

Btw, this will also be important for the future FINAL implementation.

[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-12-05
                 CC|                            |burnus at gcc dot gnu.org
            Summary|Memory leak in intrinsic    |Memory leak in intrinsic
                   |assignment of allocatable   |assignment of a scalar
                   |derived type function       |allocatable function result
                   |result                      |
     Ever Confirmed|0                           |1

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-12-05 10:00:09 UTC ---
The issue seems to only occur with scalars.

Generated code

  a = *bar ();

Expected: One uses a temporary as in

  tmp = bar ();
  a = *tmp;
  free (tmp);

The same issue occurs with reallocate LHS, were also a temporary should be
used.

[Check that the allocation/freeing is properly done for variables with length
type parameter (currently only deferred-length CHARACTER strings).]

[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-12-05 10:14:03 UTC ---
(In reply to comment #1)
> The problem seems to be that we fail to do auto-deallocation of the function
> result (after the assignment). One should check the standard, if and where this
> is actually demanded.

Nowhere. It only falls into the category "quality of implementation". But a
reasonable place would be after the place where finalization would occur.


> Btw, this will also be important for the future FINAL implementation.

Yes, after the function has evaluated, its result has to be finalized. I think
it should be as following:

tmp = bar();
final_wrapper (a);  ! must be after "bar()"
a = *tmp;
final_wrapper (*tmp);
free (tmp);

With an allocatable LHS it gets messier due to the length type parameter (and
shape). In addition, it seems as if one had always to finalize the LHS in an
intrinsic assignment while the (re)allocation is only allowed if the shape
doesn't match.


>From F2008, "4.5.6.3 When finalization occurs":

"If an executable construct references a function, the result is finalized
after execution of the innermost executable construct containing the
reference."

"When an intrinsic assignment statement is executed, the variable is finalized
after evaluation of expr and before the definition of the variable."


By the way, the latter implies that a temporary variable has to be used if
there is a finalizer and the RHS doesn't return a pointer/allocatable.
Otherwise one had to finalize the LHS before evaluating the RHS expr.

[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603

--- Comment #4 from janus at gcc dot gnu.org 2012-12-28 16:01:57 UTC ---
(In reply to comment #2)
> The issue seems to only occur with scalars.

Right. When using an array in Damian's test case, a temporary is generated by
calling gfc_trans_create_temp_array from gfc_conv_procedure_call
(trans-expr.c:4979).

[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result

[damian at rouson dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603

--- Comment #5 from Damian Rouson <damian at rouson dot net> 2013-01-20 18:59:54 UTC ---
Hi Janus and Tobias,

We're moving toward an internal release of the open-source package that exposed
this bug.  Any chance of this being fixed in the near future?  The lead
developer Karla Morris is cc'd on this. 

Damian

[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwmwalrus at gmail dot com

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
*** Bug 58229 has been marked as a duplicate of this bug. ***

[Bug fortran/55603] Memory leak in intrinsic assignment of a scalar allocatable function result

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55603

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
*** Bug 46487 has been marked as a duplicate of this bug. ***

[Bug fortran/55603] [F03] Memory leak with scalar allocatable function result

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
PR 60913 is closely related and contains a more complicated test case.

[Bug fortran/55603] [F03] Memory leak with scalar allocatable function result

[mikael at gcc dot gnu.org]

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

--- Comment #10 from Mikael Morin <mikael at gcc dot gnu.org> ---
Author: mikael
Date: Fri Sep 25 20:28:33 2015
New Revision: 228151

URL: https://gcc.gnu.org/viewcvs?rev=228151&root=gcc&view=rev
Log:
Add PR fortran/55603 working test

gcc/testsuite/
        PR fortran/55603
        * gfortran.dg/allocatable_function_9.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/allocatable_function_9.f90
Modified:
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/55603] [F03] Memory leak with scalar allocatable function result

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
      Known to work|                            |6.0
         Resolution|---                         |FIXED

--- Comment #11 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Mikael Morin from comment #9)
> It seems to work with current trunk.  FIXED?

I have just committed the test. I'm closing this PR.