[Bug fortran/53389] New: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result.

[Bug fortran/53389] New: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result.

[stephan.kramer at imperial dot ac.uk]

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

             Bug #: 53389
           Summary: memory leak when assigning array function result to
                    allocatable array, where one of its supplied arguments
                    is itself an array function result.
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: stephan.kramer@imperial.ac.uk


The following test code leaks memory rapidly - reproduced on Ubuntu's gfortran
4.6.3, with gfortran 4.7.1 and with a nightly build of 4.8, trunk revision
187620 - default optimisation flags (none specified). As far as I've narrowed
it down, it seems to occur when an array function result is assigned to an
allocatable array, where one of the arguments supplied to this function is
itself an array function result. In the example below, the outer function and
the function supplied as an argument are the same, and the returned array is an
automatic array, but that does not seems to be necessary to reproduce the
problem.

module foo
  implicit none
  contains

  function filler(array, val)
    real, dimension(:), intent(in):: array
    real, dimension(size(array)):: filler
    real, intent(in):: val

    filler=val

  end function filler
end module

program test
  use foo
  implicit none

  real, dimension(:), allocatable:: x, y
  integer, parameter:: N=1000*1000
  integer:: i

  allocate( x(N), y(N) )
  y=0.0

  do i=1, N
    print *,i
    x=filler(filler(y, real(2*i)), real(i))
    y=y+x
  end do

end program test

[Bug fortran/53389] memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-05-17
                 CC|                            |kargl at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #1 from kargl at gcc dot gnu.org 2012-05-17 17:13:41 UTC ---
Confirmed.

Workaround is to use -fno-realloc-lhs

[Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
                 CC|                            |burnus at gcc dot gnu.org,
                   |                            |pault at gcc dot gnu.org
      Known to work|                            |4.5.3
   Target Milestone|---                         |4.6.4
            Summary|memory leak when assigning  |[4.6/4.7/4.8 Regression]
                   |array function result to    |-frealloc-lhs: memory leak
                   |allocatable array, where    |when assigning array
                   |one of its supplied         |function result to
                   |arguments is itself an      |allocatable array, where
                   |array function result.      |one of its supplied
                   |                            |arguments is itself an
                   |                            |array function result
      Known to fail|                            |4.6.3, 4.7.1, 4.8.0

[Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result

[stephan.kramer at imperial dot ac.uk]

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

--- Comment #2 from Stephan Kramer <stephan.kramer at imperial dot ac.uk> 2012-05-18 15:27:54 UTC ---
(In reply to comment #1)
> Confirmed.
> 
> Workaround is to use -fno-realloc-lhs

Excellent. Thanks for the suggested workaround. That'll save us a lot of
unnecessary refactoring.

[Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-05-18 17:05:57 UTC ---
(In reply to comment #0)
>     x=filler(filler(y, real(2*i)), real(i))

That line should call "filler" twice, however, it is called trice! There are
two "atmps" - on the second is properly freed. If one does a backtrace in
gfc_trans_create_temp_array, one sees:

#0                        gfc_trans_create_temp_array at  trans-array.c:986
#1  0x00000000005f009f in gfc_conv_procedure_call     at  trans-expr.c:4326 <<<
...
#8  0x00000000005f0dce in gfc_conv_function_expr      at  trans-expr.c:4885
#9  0x00000000005d0999 in gfc_add_loop_ss_code        at  trans-array.c:2514
#10 0x00000000005d1626 in gfc_conv_loop_setup         at  trans-array.c:4542
#11 0x00000000005f671b in realloc_lhs_loop_for_fcn_call at trans-expr.c:6342
#12                       gfc_trans_arrayfunc_assign  at  trans-expr.c:6522 
<<<


#0                        gfc_trans_create_temp_array at  trans-array.c:986
#1  0x00000000005f009f in gfc_conv_procedure_call     at  trans-expr.c:4326 
<<<
...
#8  0x00000000005f0dce in gfc_conv_function_expr      at  trans-expr.c:4885
#9  0x00000000005f61fd in gfc_trans_arrayfunc_assign  at  trans-expr.c:6532 <<<


trans-expr.c has in gfc_trans_arrayfunc_assign the following, which looks fine:

  6517      {
  6518        realloc_lhs_warning (expr1->ts.type, true, &expr1->where);
  6519  
  6520        if (!expr2->value.function.isym)
  6521          {
  6522            realloc_lhs_loop_for_fcn_call (&se, &expr1->where, &ss,
&loop);
  6523            ss->is_alloc_lhs = 1;
  6524          }
  6525        else
  6526          fcncall_realloc_result (&se, expr1->rank);
  6527      }
  6528  
  6529    gfc_conv_function_expr (&se, expr2);
  6530    gfc_add_block_to_block (&se.pre, &se.post);
  6531  
  6532    return gfc_finish_block (&se.pre);
  6533  }

However, in gfc_conv_procedure_call the "if" should evaluate true for the
second call - but it does not! Thus, another temporary array is generated and a
second call is inserted.

  4312            if (gfc_option.flag_realloc_lhs
  4313                  && se->ss && se->ss->is_alloc_lhs)
  4314              {
  4315                gfc_free_interface_mapping (&mapping);
  4316                return has_alternate_specifier;
  4317              }
  4318  
  4319            /* Create a temporary to store the result.  In case the
function
  4320               returns a pointer, the temporary will be a shallow copy
and
  4321               mustn't be deallocated.  */
  4322            callee_alloc = sym->attr.allocatable || sym->attr.pointer;
  4323            gfc_trans_create_temp_array (&se->pre, &se->post, se->ss,
  4324                                         tmp, NULL_TREE, false,
  4325                                         !sym->attr.pointer,
callee_alloc,
  4326                                         &se->ss->info->expr->where);

[Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result

[burnus at gcc dot gnu.org]

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

--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-05-21 16:16:24 UTC ---
If one duplicates "filler" and renames it to inner/outer with the call:
  x=outer(inner(y, real(2*i)), real(i))

one sees four calls to gfc_conv_procedure_call for: outer, inner, outer, inner.
Everything starts in gfc_trans_arrayfunc_assign:

The first ("outer") is via realloc_lhs_loop_for_fcn_call which has
se->ss->is_alloc_lhs == 1.

The second is for "inner" via gfc_conv_procedure_call -> gfc_conv_function_expr
-> gfc_conv_procedure_call, which uses gfc_trans_create_temp_array.

One then returns to the first call ("outer"), which stops at
gfc_free_interface_mapping as ss->is_alloc_lhs == 1.

Back in gfc_trans_arrayfunc_assign, one now calls gfc_conv_function_expr for
"outer", which again calls via gfc_conv_function_expr the function
gfc_conv_procedure_call for "inner" - which calls gfc_trans_create_temp_array.

Fourth, one is back in gfc_conv_procedure_callwhere one calls
gfc_alloc_allocatable_for_assignment.

Thus, the inner function is evaluated twice.


 * * *


Draft patch: Fixes the issue at hand for allocated/nonallocated "X" (according
to valgrind and dump inspection) and successfully regtests the
realloc_on_assign_*.f* test cases.


--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -2401,6 +2401,11 @@ gfc_add_loop_ss_code (gfc_loopinfo * loop, gfc_ss * ss,
bool subscript,
   bool skip_nested = false;
   int n;

+  /* Don't evaluate the arguments for realloc_lhs_loop_for_fcn_call;
otherwise,
+     arguments could get evaluated multiple times.  */
+  if (ss->is_alloc_lhs)
+    return;
+
   outer_loop = outermost_loop (loop);

   /* TODO: This can generate bad code if there are ordering dependencies,

[Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-05-22 10:10:55 UTC ---
Author: burnus
Date: Tue May 22 10:10:47 2012
New Revision: 187769

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187769
Log:
2012-05-22  Tobias Burnus  <burnus@net-b.de>

        PR fortran/53389
        * trans-array.c (gfc_add_loop_ss_code): Don't evaluate
        * expression, if
        ss->is_alloc_lhs is set.

2012-05-22  Tobias Burnus  <burnus@net-b.de>

        PR fortran/53389
        * gfortran.dg/realloc_on_assign_15.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_15.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-05-23 19:08:56 UTC ---
Author: burnus
Date: Wed May 23 19:08:52 2012
New Revision: 187808

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187808
Log:
2012-05-23  Tobias Burnus  <burnus@net-b.de>

        PR fortran/53389
        * trans-array.c (gfc_add_loop_ss_code): Don't evaluate
        * expression, if
        ss->is_alloc_lhs is set.

2012-05-23  Tobias Burnus  <burnus@net-b.de>

        PR fortran/53389
        * gfortran.dg/realloc_on_assign_15.f90: New.


Added:
    branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/realloc_on_assign_15.f90
Modified:
    branches/gcc-4_7-branch/gcc/fortran/ChangeLog
    branches/gcc-4_7-branch/gcc/fortran/trans-array.c
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-05-23 19:13:34 UTC ---
Author: burnus
Date: Wed May 23 19:13:27 2012
New Revision: 187810

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187810
Log:
2012-05-23  Tobias Burnus  <burnus@net-b.de>

        PR fortran/53389
        * trans-array.c (gfc_add_loop_ss_code): Don't evaluate
        expression, if ss->is_alloc_lhs is set.

2012-05-23  Tobias Burnus  <burnus@net-b.de>

        PR fortran/53389
        * gfortran.dg/realloc_on_assign_15.f90: New.


Added:
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/realloc_on_assign_15.f90
Modified:
    branches/gcc-4_6-branch/gcc/fortran/ChangeLog
    branches/gcc-4_6-branch/gcc/fortran/trans-array.c
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog

[Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: memory leak when assigning array function result to allocatable array, where one of its supplied arguments is itself an array function result

[burnus at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-05-23 19:15:27 UTC ---
FIXED on the trunk (4.8) and all (both) affected branches: 4.6 and 4.7.

Thanks for the bug report and sorry for the regression!