[Bug fortran/66082] memory leak with automatic array dummy argument with derived type array constructor actual argument

[pault at gcc dot gnu.org]

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

--- Comment #7 from Paul Thomas  ---
Author: pault
Date: Sun Jan 17 17:34:12 2016
New Revision: 232482

URL: https://gcc.gnu.org/viewcvs?rev=232482=gcc=rev
Log:
2016-01-17  Mikael Morin  

Backport from trunk.
PR fortran/61831
* gfortran.dg/derived_constructor_components_6.f90: New file.
* gfortran.dg/allocate_with_source_14.f03: Change count of
__builtin_malloc from 21 to 23.

2016-01-17  Paul Thomas  

Backport from trunk.
PR fortran/66082
* gfortran.dg/alloc_comp_auto_array_3.f90: New file. Count of
__builtin_malloc increased from 3 to 4, relative to trunk.

2016-01-17  Mikael Morin  
Dominique d'Humieres  

Backport from trunk.
PR fortran/61831
* trans-array.c (gfc_conv_array_parameter): Guard allocatable
component deallocation code generation with descriptorless
calling convention flag.
* trans-expr.c (gfc_conv_expr_reference): Remove allocatable
component deallocation code generation from revision 212329.
(expr_may_alias_variables): New function.
(gfc_conv_procedure_call): New boolean elemental_proc to factor
check for procedure elemental-ness.  Rename boolean f to nodesc_arg
and declare it in the outer scope.  Use expr_may_alias_variables,
elemental_proc and nodesc_arg to decide whether generate allocatable
component deallocation code.
(gfc_trans_subarray_assign): Set deep copy flag.

2016-01-17  Paul Thomas  

Backport from trunk.
PR fortran/66082
* trans-array.c (gfc_conv_array_parameter): Ensure that all
non-variable arrays with allocatable components have the
components deallocated after the procedure call.


Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/alloc_comp_auto_array_3.f90
   
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/derived_constructor_comps_6.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-array.c
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocate_with_source_14.f03

[Bug fortran/66082] memory leak with automatic array dummy argument with derived type array constructor actual argument

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Paul Thomas  ---
Dear Mikael,

There is no reason at all why it is not closed! Doing so now.

Cheers

Paul

[Bug fortran/66082] memory leak with automatic array dummy argument with derived type array constructor actual argument

[mikael at gcc dot gnu.org]

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

--- Comment #5 from Mikael Morin mikael at gcc dot gnu.org ---
Paul, is there something to be done before closing?

[Bug fortran/66082] memory leak with automatic array dummy argument with derived type array constructor actual argument

[damian at sourceryinstitute dot org]

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

--- Comment #4 from Damian Rouson damian at sourceryinstitute dot org ---
Thanks for fixing this!  I just verified that the leak is gone with a gcc build
dated 20150607.

Damian

[Bug fortran/66082] memory leak with automatic array dummy argument with derived type array constructor actual argument

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas pault at gcc dot gnu.org ---
Author: pault
Date: Tue May 26 10:20:41 2015
New Revision: 223677

URL: https://gcc.gnu.org/viewcvs?rev=223677root=gccview=rev
Log:
2015-05-26  Paul Thomas  pa...@gcc.gnu.org

PR fortran/66082
* trans-array.c (gfc_conv_array_parameter): Ensure that all
non-variable arrays with allocatable components have the
components deallocated after the procedure call.

2015-05-26  Paul Thomas  pa...@gcc.gnu.org

PR fortran/66082
* gfortran.dg/allocatable_scalar_13.f90: New test

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

[Bug fortran/66082] memory leak with automatic array dummy argument with derived type array constructor actual argument

[pault at gcc dot gnu.org]

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

Paul Thomas pault at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-05-23
 CC||pault at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Paul Thomas pault at gcc dot gnu.org ---
Confirmed.

Oddly, the memory leak goes away at any level of optimization. What makes this
odd is that the assumed shape array case has all the code for deallocation of
the allocatable component after the call to foo_1d:

  foo_1d (C.3401, atmp.3);
  if ((struct foo_t[1] * restrict) atmp.3.data != 0B)
{
  D.3411 = (atmp.3.dim[0].ubound - atmp.3.dim[0].lbound) + 1;
  D.3412 = atmp.3.dim[0].stride * D.3411;
  D.3413 = D.3412 + -1;
  S.6 = 0;
  while (1)
{
  if (S.6  D.3413) goto L.3;
  if ((*(struct foo_t[1] * restrict) atmp.3.data)[S.6].bigarr
!= 0B)
{
  __builtin_free ((void *) (*(struct foo_t[1] * restrict)
atmp.3.data)[S.6].bigarr);
}
  (*(struct foo_t[1] * restrict) atmp.3.data)[S.6].bigarr = 0B;
  S.6 = S.6 + 1;
}
  L.3:;
}

and this disappears completely for the automatic array dummy. I am pretty sure
that ther problem lies in trans-array.c(gfc_conv_array_parameter), where the
deallocation of allocatable components appears after the return for g77 style
dummies. I cannot check this right now because I am doing a fresh bootstrap
with a clean tree.

Paul

[Bug fortran/66082] memory leak with automatic array dummy argument with derived type array constructor actual argument

[mikael at gcc dot gnu.org]

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

Mikael Morin mikael at gcc dot gnu.org changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #2 from Mikael Morin mikael at gcc dot gnu.org ---
PR61831 is possibly related.
But I don't think the PR61831 patch fixes this.