* [Bug fortran/47637] [OOP] Memory leak involving INTENT(OUT) CLASS argument w/ allocatable components
2011-02-07 22:15 [Bug fortran/47637] New: Memory leak involving derived types w/ allocatable components townsend at astro dot wisc.edu
@ 2011-02-08 20:16 ` janus at gcc dot gnu.org
2011-02-08 22:51 ` janus at gcc dot gnu.org
` (4 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-08 20:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47637
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011.02.08 20:14:11
CC| |janus at gcc dot gnu.org
Summary|Memory leak involving |[OOP] Memory leak involving
|derived types w/ |INTENT(OUT) CLASS argument
|allocatable components |w/ allocatable components
Ever Confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org 2011-02-08 20:14:11 UTC ---
Confirmed. Here is a shorter example with the same symptoms:
program leaky
type :: t
integer, allocatable :: i(:)
end type
type(t) :: a
call init(a)
call init(a)
contains
subroutine init(x)
class(t), intent(out) :: x
allocate(x%i(1000))
end subroutine
end program
Note that the memory leak only occurs with a CLASS argument, not with TYPE.
Also the auto-dealloc at the end of the main program works correctly, so that
we only lose one of the two allocations.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/47637] [OOP] Memory leak involving INTENT(OUT) CLASS argument w/ allocatable components
2011-02-07 22:15 [Bug fortran/47637] New: Memory leak involving derived types w/ allocatable components townsend at astro dot wisc.edu
2011-02-08 20:16 ` [Bug fortran/47637] [OOP] Memory leak involving INTENT(OUT) CLASS argument " janus at gcc dot gnu.org
@ 2011-02-08 22:51 ` janus at gcc dot gnu.org
2011-02-09 10:01 ` janus at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-08 22:51 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47637
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 #2 from janus at gcc dot gnu.org 2011-02-08 22:38:15 UTC ---
Something like this should fix it:
Index: gcc/fortran/trans-decl.c
===================================================================
--- gcc/fortran/trans-decl.c (revision 169891)
+++ gcc/fortran/trans-decl.c (working copy)
@@ -3192,7 +3192,35 @@ init_intent_out_dt (gfc_symbol * proc_sym, gfc_wra
else if (f->sym->value)
gfc_init_default_dt (f->sym, &init, true);
}
+ else if (f->sym && f->sym->attr.intent == INTENT_OUT
+ && f->sym->ts.type == BT_CLASS
+ && !CLASS_DATA (f->sym)->attr.class_pointer
+ && CLASS_DATA (f->sym)->ts.u.derived->attr.alloc_comp)
+ {
+ tree decl = build_fold_indirect_ref_loc (input_location,
+ f->sym->backend_decl);
+ tmp = CLASS_DATA (f->sym)->backend_decl;
+ tmp = fold_build3_loc (input_location, COMPONENT_REF,
+ TREE_TYPE (tmp), decl,
+ tmp, NULL_TREE);
+ tmp = build_fold_indirect_ref_loc (input_location, tmp);
+ tmp = gfc_deallocate_alloc_comp (CLASS_DATA (f->sym)->ts.u.derived,
+ tmp,
+ CLASS_DATA (f->sym)->as ?
+ CLASS_DATA (f->sym)->as->rank : 0);
+ if (f->sym->attr.optional
+ || f->sym->ns->proc_name->attr.entry_master)
+ {
+ present = gfc_conv_expr_present (f->sym);
+ tmp = build3_loc (input_location, COND_EXPR, TREE_TYPE (tmp),
+ present, tmp,
+ build_empty_stmt (input_location));
+ }
+
+ gfc_add_expr_to_block (&init, tmp);
+ }
+
gfc_add_init_cleanup (block, gfc_finish_block (&init), NULL_TREE);
}
This gets rid of the memleaks in both comment #0 and comment #1 for me, but is
not regtested yet.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/47637] [OOP] Memory leak involving INTENT(OUT) CLASS argument w/ allocatable components
2011-02-07 22:15 [Bug fortran/47637] New: Memory leak involving derived types w/ allocatable components townsend at astro dot wisc.edu
2011-02-08 20:16 ` [Bug fortran/47637] [OOP] Memory leak involving INTENT(OUT) CLASS argument " janus at gcc dot gnu.org
2011-02-08 22:51 ` janus at gcc dot gnu.org
@ 2011-02-09 10:01 ` janus at gcc dot gnu.org
2011-02-09 14:10 ` burnus at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 7+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-09 10:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47637
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
--- Comment #3 from janus at gcc dot gnu.org 2011-02-09 09:56:31 UTC ---
The patch in comment #2 regtests cleanly on x86_64-unknown-linux-gnu, without
any failures.
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/47637] [OOP] Memory leak involving INTENT(OUT) CLASS argument w/ allocatable components
2011-02-07 22:15 [Bug fortran/47637] New: Memory leak involving derived types w/ allocatable components townsend at astro dot wisc.edu
` (2 preceding siblings ...)
2011-02-09 10:01 ` janus at gcc dot gnu.org
@ 2011-02-09 14:10 ` burnus at gcc dot gnu.org
2011-02-09 16:01 ` janus at gcc dot gnu.org
2011-02-09 16:05 ` janus at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-02-09 14:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47637
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-09 14:02:58 UTC ---
See bug 46321 regarding the required full solution for polymophic allocatables.
Special case solution, cf. approved patch at
http://gcc.gnu.org/ml/fortran/2011-02/msg00067.html
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/47637] [OOP] Memory leak involving INTENT(OUT) CLASS argument w/ allocatable components
2011-02-07 22:15 [Bug fortran/47637] New: Memory leak involving derived types w/ allocatable components townsend at astro dot wisc.edu
` (3 preceding siblings ...)
2011-02-09 14:10 ` burnus at gcc dot gnu.org
@ 2011-02-09 16:01 ` janus at gcc dot gnu.org
2011-02-09 16:05 ` janus at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-09 16:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47637
--- Comment #5 from janus at gcc dot gnu.org 2011-02-09 15:58:11 UTC ---
Author: janus
Date: Wed Feb 9 15:58:05 2011
New Revision: 169978
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169978
Log:
2011-02-09 Janus Weil <janus@gcc.gnu.org>
PR fortran/47637
* trans-decl.c (init_intent_out_dt): Handle CLASS arguments.
2011-02-09 Janus Weil <janus@gcc.gnu.org>
PR fortran/47637
* gfortran.dg/auto_dealloc_2.f90: New.
Added:
trunk/gcc/testsuite/gfortran.dg/auto_dealloc_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-decl.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 7+ messages in thread
* [Bug fortran/47637] [OOP] Memory leak involving INTENT(OUT) CLASS argument w/ allocatable components
2011-02-07 22:15 [Bug fortran/47637] New: Memory leak involving derived types w/ allocatable components townsend at astro dot wisc.edu
` (4 preceding siblings ...)
2011-02-09 16:01 ` janus at gcc dot gnu.org
@ 2011-02-09 16:05 ` janus at gcc dot gnu.org
5 siblings, 0 replies; 7+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-09 16:05 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47637
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #6 from janus at gcc dot gnu.org 2011-02-09 16:01:04 UTC ---
Fixed with r169978. Thanks for the report, Rich!
Note that further memory leaks are to expected for cases where the dynamic type
is different from the declared type (and has additional allocatable
components), cf. PR 46321.
^ permalink raw reply [flat|nested] 7+ messages in thread