[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 --- Comment #10 from janus at gcc dot gnu.org 2011-07-02 13:46:23 UTC --- Author: janus Date: Sat Jul 2 13:46:21 2011 New Revision: 175780 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175780 Log: 2011-07-02 Janus Weil ja...@gcc.gnu.org PR fortran/49466 * trans-array.c (structure_alloc_comps): Make sure sub-components and extended types are correctly deallocated. 2011-07-02 Janus Weil ja...@gcc.gnu.org PR fortran/49466 * gfortran.dg/allocatable_scalar_9.f90: Modified. * gfortran.dg/extends_14.f03: New. Added: branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/extends_14.f03 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 branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90
[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #11 from janus at gcc dot gnu.org 2011-07-02 13:52:18 UTC --- Fixed on trunk and the 4.6 branch. This means that the fix will be part of the upcoming release 4.6.2, which is tentatively scheduled for September. Thanks for reporting, Rich!
[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #8 from janus at gcc dot gnu.org 2011-06-27 17:33:19 UTC ---
(In reply to comment #7)
This is due to revision 165973:
... and fixed by a partial revert of this commit (see below), which is free of
testsuite regressions. Will commit as obvious soon (unfortunately too late for
the 4.6.1 release).
Index: gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90
===
--- gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90(revision 175536)
+++ gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90(working copy)
@@ -49,7 +49,7 @@ if(allocated(na3%b3)) call abort()
if(allocated(na4%b4)) call abort()
end
-! { dg-final { scan-tree-dump-times __builtin_free 32 original } }
+! { dg-final { scan-tree-dump-times __builtin_free 38 original } }
! { dg-final { cleanup-tree-dump original } }
! { dg-final { cleanup-modules m } }
Index: gcc/fortran/trans-array.c
===
--- gcc/fortran/trans-array.c(revision 175536)
+++ gcc/fortran/trans-array.c(working copy)
@@ -6682,18 +6682,22 @@ structure_alloc_comps (gfc_symbol * der_type, tree
switch (purpose)
{
case DEALLOCATE_ALLOC_COMP:
+ if (cmp_has_alloc_comps !c-attr.pointer)
+{
+ /* Do not deallocate the components of ultimate pointer
+ components. */
+ comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
+ decl, cdecl, NULL_TREE);
+ rank = c-as ? c-as-rank : 0;
+ tmp = structure_alloc_comps (c-ts.u.derived, comp, NULL_TREE,
+ rank, purpose);
+ gfc_add_expr_to_block (fnblock, tmp);
+}
+
if (c-attr.allocatable c-attr.dimension)
{
comp = fold_build3_loc (input_location, COMPONENT_REF, ctype,
decl, cdecl, NULL_TREE);
- if (cmp_has_alloc_comps !c-attr.pointer)
-{
- /* Do not deallocate the components of ultimate pointer
- components. */
- tmp = structure_alloc_comps (c-ts.u.derived, comp, NULL_TREE,
- c-as-rank, purpose);
- gfc_add_expr_to_block (fnblock, tmp);
-}
tmp = gfc_trans_dealloc_allocated (comp);
gfc_add_expr_to_block (fnblock, tmp);
}
[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 --- Comment #9 from janus at gcc dot gnu.org 2011-06-27 20:59:16 UTC --- Author: janus Date: Mon Jun 27 20:59:12 2011 New Revision: 175563 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=175563 Log: 2011-06-27 Janus Weil ja...@gcc.gnu.org PR fortran/49466 * trans-array.c (structure_alloc_comps): Make sure sub-components and extended types are correctly deallocated. 2011-06-27 Janus Weil ja...@gcc.gnu.org PR fortran/49466 * gfortran.dg/allocatable_scalar_9.f90: Modified. * gfortran.dg/extends_14.f03: Modified. Added: trunk/gcc/testsuite/gfortran.dg/extends_14.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_9.f90
[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-20 06:21:27 UTC --- This is due to revision 165973: Author:janus Date:Tue Oct 26 17:38:42 2010 UTC (7 months, 3 weeks ago) Changed paths:10 Log Message: 2010-10-26 Janus Weil ja...@gcc.gnu.org PR fortran/42647 * trans.h (gfc_deallocate_scalar_with_status): New prototype. * trans.c (gfc_deallocate_scalar_with_status): New function for deallocation of allocatable scalars. * trans-array.c (structure_alloc_comps): Call it here ... * trans-decl.c (gfc_trans_deferred_vars): ... here ... * trans-stmt.c (gfc_trans_deallocate): ... and here. 2010-10-26 Janus Weil ja...@gcc.gnu.org PR fortran/42647 * gfortran.dg/allocatable_scalar_9.f90: Extended. * gfortran.dg/allocatable_scalar_10.f90: New. * gfortran.dg/class_19.f03: Extended. Another test: program evolve_aflow implicit none type :: state_t real, allocatable :: U(:) end type state_t type, extends(state_t) :: astate_t end type astate_t type(astate_t) :: a,b allocate(a%U(1000)) allocate(b%U(1000)) ! b%U = a%U a = b deallocate(a%U, b%U) end program
[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 janus at gcc dot gnu.org changed: What|Removed |Added Summary|Memory leak with assignment |[4.6/4.7 Regression] Memory |of extended derived types |leak with assignment of ||extended derived types --- Comment #4 from janus at gcc dot gnu.org 2011-06-19 17:52:35 UTC --- (In reply to comment #3) I see (with valgrind on x86_64-apple-darwin10) the memory leak for gcc 4.6 (revision 166102) and trunk, but not for gcc 4.5.2 or 4.6 revision 162456. Ok, I can also reproduce the memory leak with gfortran 4.7 on x86_64-unknown-linux-gnu, which means that it is a regression. Here is a reduced test case: program evolve_aflow implicit none type :: state_t real, allocatable :: U(:) end type state_t type, extends(state_t) :: astate_t end type astate_t type(astate_t) :: a,b allocate(a%U(1000)) b = a b = a end program In the first assignment b.U is allocated, in the second assignment it is not freed, before being allocated again. In fact, the dump does not contain a single __builtin_free, while with 4.5 it has six. valgrind says: ==27163== 4,000 bytes in 1 blocks are definitely lost in loss record 3 of 3 ==27163==at 0x4C2683D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27163==by 0x4009BC: MAIN__ (test.f90:16) ==27163==by 0x400B9D: main (test.f90:19)
[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-06-19 18:45:09 UTC --- In the first assignment b.U is allocated, in the second assignment it is not freed, before being allocated again. I don't think it should be freed then allocated for the second assignment in the code in comment#4.
[Bug fortran/49466] [4.6/4.7 Regression] Memory leak with assignment of extended derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49466 --- Comment #6 from Rich Townsend townsend at astro dot wisc.edu 2011-06-19 18:57:40 UTC --- (In reply to comment #5) In the first assignment b.U is allocated, in the second assignment it is not freed, before being allocated again. I don't think it should be freed then allocated for the second assignment in the code in comment#4. Certainly, given that the lhs array component is the same shape as the rhs array component, an optimization would be not to free and then allocate the array prior to the copy. However, that doesn't alter the fact that the behavior should be *as if* the lhs array component were freed and then allocated with the appropriate shape. This behavior has been in Fortran since TR 15581, which first introduced allocatable derived-type components as an extension to Fortran 95.
