public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/41936] Memory leakage with allocatables and user-defined operators
[not found] <bug-41936-4@http.gcc.gnu.org/bugzilla/>
@ 2011-02-28 21:59 ` mikael at gcc dot gnu.org
2014-04-27 14:05 ` dominiq at lps dot ens.fr
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: mikael at gcc dot gnu.org @ 2011-02-28 21:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |patch
CC| |mikael at gcc dot gnu.org
--- Comment #2 from Mikael Morin <mikael at gcc dot gnu.org> 2011-02-28 21:22:39 UTC ---
Fixed if one adds the code below (copied from gfc_conv_array_parameter).
I'm afraid this could change a memory leak into a double free (see PR 40850).
Also, not quite right (even if the middle-end optimizers are likely to fix it)
because it adds cleanup code to both foo and bar.
diff --git a/trans-expr.c b/trans-expr.c
index d6c1f9f..3919870 100644
--- a/trans-expr.c
+++ b/trans-expr.c
@@ -4900,6 +4900,19 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr)
/* Take the address of that value. */
se->expr = gfc_build_addr_expr (NULL_TREE, var);
+ if ((expr->ts.type == BT_DERIVED || expr->ts.type == BT_CLASS)
+ && expr->ts.u.derived->attr.alloc_comp
+ && expr->expr_type != EXPR_VARIABLE)
+ {
+ tree tmp;
+
+ tmp = build_fold_indirect_ref_loc (input_location, se->expr);
+ tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
+
+ /* The components shall be deallocated before
+ their containing entity. */
+ gfc_prepend_expr_to_block (&se->post, tmp);
+ }
}
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41936] Memory leakage with allocatables and user-defined operators
[not found] <bug-41936-4@http.gcc.gnu.org/bugzilla/>
2011-02-28 21:59 ` [Bug fortran/41936] Memory leakage with allocatables and user-defined operators mikael at gcc dot gnu.org
@ 2014-04-27 14:05 ` dominiq at lps dot ens.fr
2014-04-27 14:32 ` burnus at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-04-27 14:05 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936
--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Fixed if one adds the code below (copied from gfc_conv_array_parameter).
> I'm afraid this could change a memory leak into a double free (see PR 40850).
> Also, not quite right (even if the middle-end optimizers are likely to fix it)
> because it adds cleanup code to both foo and bar.
With the patch in comment 2, the tests gfortran.dg/alloc_comp_basics_1.f90 and
gfortran.dg/alloc_comp_constructor_1.f90 fail because there are 21 occurrences
of "builtin_free". This is fixed by the following updated patch (against
r209838)
--- ../_clean/gcc/fortran/trans-expr.c 2014-04-25 14:30:23.000000000 +0200
+++ gcc/fortran/trans-expr.c 2014-04-27 16:03:28.000000000 +0200
@@ -6474,6 +6474,19 @@ gfc_conv_expr_reference (gfc_se * se, gf
/* Take the address of that value. */
se->expr = gfc_build_addr_expr (NULL_TREE, var);
+ if ((expr->ts.type == BT_DERIVED || expr->ts.type == BT_CLASS)
+ && expr->ts.u.derived->attr.alloc_comp && expr->rank
+ && expr->expr_type != EXPR_VARIABLE)
+ {
+ tree tmp;
+
+ tmp = build_fold_indirect_ref_loc (input_location, se->expr);
+ tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
+
+ /* The components shall be deallocated before
+ their containing entity. */
+ gfc_prepend_expr_to_block (&se->post, tmp);
+ }
}
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41936] Memory leakage with allocatables and user-defined operators
[not found] <bug-41936-4@http.gcc.gnu.org/bugzilla/>
2011-02-28 21:59 ` [Bug fortran/41936] Memory leakage with allocatables and user-defined operators mikael at gcc dot gnu.org
2014-04-27 14:05 ` dominiq at lps dot ens.fr
@ 2014-04-27 14:32 ` burnus at gcc dot gnu.org
2014-04-27 14:47 ` dominiq at lps dot ens.fr
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-04-27 14:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #3)
> + if ((expr->ts.type == BT_DERIVED || expr->ts.type == BT_CLASS)
> + && expr->ts.u.derived->attr.alloc_comp && expr->rank
> + && expr->expr_type != EXPR_VARIABLE)
> + {
> + tmp = build_fold_indirect_ref_loc (input_location, se->expr);
> + tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
Calling gfc_deallocate_alloc_comp for BT_CLASS looks wrong. You have to call
the finalization wrapper - to ensure that not only the allocatable components
of the declared type but also the ones of the effective/actual type are
deallocated. Additionally, that ensure that user's finalizer is called when it
exists.
(For BT_DERIVED, you may also have to call the finalization wrapper - but only
if the type has finalizers.)
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41936] Memory leakage with allocatables and user-defined operators
[not found] <bug-41936-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2014-04-27 14:32 ` burnus at gcc dot gnu.org
@ 2014-04-27 14:47 ` dominiq at lps dot ens.fr
2014-05-04 10:06 ` dominiq at lps dot ens.fr
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-04-27 14:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936
--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Calling gfc_deallocate_alloc_comp for BT_CLASS looks wrong. ...
I have only added " && expr->rank" to the three year old Mikael's patch.
> You have to call the finalization wrapper - to ensure that not only the
> allocatable components of the declared type but also the ones of the
> effective/actual type are deallocated. Additionally, that ensure that
> user's finalizer is called when it exists.
>
> (For BT_DERIVED, you may also have to call the finalization wrapper - but only
> if the type has finalizers.)
Could you please provide a more explicit pointer?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41936] Memory leakage with allocatables and user-defined operators
[not found] <bug-41936-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2014-04-27 14:47 ` dominiq at lps dot ens.fr
@ 2014-05-04 10:06 ` dominiq at lps dot ens.fr
2014-06-10 11:43 ` dominiq at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-05-04 10:06 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936
--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Is the following patch OK?
--- ../_clean/gcc/fortran/trans-expr.c 2014-04-30 21:41:33.000000000 +0200
+++ gcc/fortran/trans-expr.c 2014-05-04 00:42:50.000000000 +0200
@@ -6504,6 +6504,20 @@ gfc_conv_expr_reference (gfc_se * se, gf
/* Take the address of that value. */
se->expr = gfc_build_addr_expr (NULL_TREE, var);
+ if (expr->ts.type == BT_DERIVED && expr->rank
+ && !gfc_is_finalizable (expr->ts.u.derived, NULL)
+ && expr->ts.u.derived->attr.alloc_comp
+ && expr->expr_type != EXPR_VARIABLE)
+ {
+ tree tmp;
+
+ tmp = build_fold_indirect_ref_loc (input_location, se->expr);
+ tmp = gfc_deallocate_alloc_comp (expr->ts.u.derived, tmp, expr->rank);
+
+ /* The components shall be deallocated before
+ their containing entity. */
+ gfc_prepend_expr_to_block (&se->post, tmp);
+ }
}
It fixes the memory leaks for the test in comment 0 and for
gfortran.dg/class_array_15.f03, but not pr55603 nor pr60913.
Is the following change for gfortran.dg/class_array_15.f03
--- ../_clean/gcc/testsuite/gfortran.dg/class_array_15.f03 2013-01-06
22:34:50.000000000 +0100
+++ gcc/testsuite/gfortran.dg/class_array_15.f03 2014-05-04
10:24:06.000000000 +0200
@@ -1,4 +1,5 @@
! { dg-do run }
+! { dg-options "-fdump-tree-original" }
!
! Tests the fixes for three bugs with the same underlying cause. All are
regressions
! that come about because class array elements end up with a different tree
type
@@ -114,3 +115,5 @@ subroutine pr54992 ! This test remains
bh => bhGet(b,instance=2)
if (loc (b) .ne. loc(bh%hostNode)) call abort
end
+! { dg-final { scan-tree-dump-times "builtin_free" 12 "original" } }
+! { dg-final { cleanup-tree-dump "original" } }
enough (there are only 11 builtin_free without the patch)? or should I add the
test in comment 0 (15 builtin_free with the patch, 12 without)?
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41936] Memory leakage with allocatables and user-defined operators
[not found] <bug-41936-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2014-05-04 10:06 ` dominiq at lps dot ens.fr
@ 2014-06-10 11:43 ` dominiq at gcc dot gnu.org
2014-07-07 12:33 ` dominiq at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: dominiq at gcc dot gnu.org @ 2014-06-10 11:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936
--- Comment #7 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Tue Jun 10 11:42:38 2014
New Revision: 211405
URL: http://gcc.gnu.org/viewcvs?rev=211405&root=gcc&view=rev
Log:
2014-06-10 Dominique d'Humieres <dominiq@lps.ens.fr>
Mikael Morin <mikael@gcc.gnu.org>
PR fortran/41936
gcc/fortran/
* trans-expr.c (gfc_conv_expr_reference): Deallocate array
components.
gcc/testsuite/
* gfortran.dg/class_array_15.f03: Check memory leaks.
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/class_array_15.f03
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41936] Memory leakage with allocatables and user-defined operators
[not found] <bug-41936-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2014-06-10 11:43 ` dominiq at gcc dot gnu.org
@ 2014-07-07 12:33 ` dominiq at gcc dot gnu.org
2014-07-07 14:00 ` dominiq at lps dot ens.fr
2014-07-07 14:00 ` dominiq at lps dot ens.fr
8 siblings, 0 replies; 10+ messages in thread
From: dominiq at gcc dot gnu.org @ 2014-07-07 12:33 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936
--- Comment #8 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Mon Jul 7 12:32:37 2014
New Revision: 212329
URL: https://gcc.gnu.org/viewcvs?rev=212329&root=gcc&view=rev
Log:
2014-07-07 Dominique d'Humieres <dominiq@lps.ens.fr>
Mikael Morin <mikael@gcc.gnu.org>
PR fortran/41936
gcc/fortran/
* trans-expr.c (gfc_conv_expr_reference): Deallocate array
components.
gcc/testsuite/
* gfortran.dg/class_array_15.f03: Check memory leaks.
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/trans-expr.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/class_array_15.f03
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41936] Memory leakage with allocatables and user-defined operators
[not found] <bug-41936-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2014-07-07 12:33 ` dominiq at gcc dot gnu.org
@ 2014-07-07 14:00 ` dominiq at lps dot ens.fr
2014-07-07 14:00 ` dominiq at lps dot ens.fr
8 siblings, 0 replies; 10+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-07-07 14:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Closing.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41936] Memory leakage with allocatables and user-defined operators
[not found] <bug-41936-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2014-07-07 14:00 ` dominiq at lps dot ens.fr
@ 2014-07-07 14:00 ` dominiq at lps dot ens.fr
8 siblings, 0 replies; 10+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-07-07 14:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|pault at gcc dot gnu.org |dominiq at lps dot ens.fr
--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Fixed on 4.9.1 and trunk (4.10.0).
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41936] New: Memory leakage with allocatables and user-defined operators
@ 2009-11-04 9:01 burnus at gcc dot gnu dot org
2009-11-12 13:51 ` [Bug fortran/41936] " pault at gcc dot gnu dot org
0 siblings, 1 reply; 10+ messages in thread
From: burnus at gcc dot gnu dot org @ 2009-11-04 9:01 UTC (permalink / raw)
To: gcc-bugs
Reported by Paul van Delst at
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/196e69ca0ed38f98
Seemingly, gfortran leaks memory with allocatables and user-defined operators.
Might be a duplicate of some other bug - I have not yet check thoroughly. I
also have not checked the code myself.
!<-----begin module my_type_define----->
module my_type_define
implicit none
private
public :: my_type
public :: assignment(=)
public :: operator(+)
public :: my_associated
public :: my_destroy
public :: my_create
public :: my_inspect
interface assignment(=)
module procedure my_assign
end interface assignment(=)
interface operator(+)
module procedure my_add
end interface operator(+)
type :: my_type
integer :: n = 0
real, allocatable :: x(:), y(:), z(:)
end type my_type
contains
! Public
elemental function my_associated( my ) result( status )
type(my_type), intent(in) :: my
logical :: status
! test the structure members
status = allocated(my%x) .or. allocated(my%y) .or. allocated(my%z)
end function my_associated
elemental subroutine my_destroy( my )
type(my_type), intent(out) :: my
end subroutine my_destroy
elemental subroutine my_create( my, n )
type(my_type), intent(out) :: my
integer, intent(in) :: n
integer :: alloc_stat
! check input
if ( n < 1 ) return
! perform the allocation
allocate( my%x(n), my%y(n), my%z(n), stat=alloc_stat )
! initialise
if ( alloc_stat == 0 ) then
! ...dimension
my%n = n
! ...arrays
my%x = 0.0
my%y = 0.0
my%z = 0.0
end if
end subroutine my_create
subroutine my_inspect( my )
type(my_type), intent(in) :: my
if ( .not. my_associated( my ) ) return
write(*,'(5x,"x:")'); write(*,'(5(1x,es13.6))') my%x
write(*,'(5x,"y:")'); write(*,'(5(1x,es13.6))') my%y
write(*,'(5x,"z:")'); write(*,'(5(1x,es13.6))') my%z
end subroutine my_inspect
! Private
elemental subroutine my_assign( copy, original )
type(my_type), intent(out) :: copy
type(my_type), intent(in) :: original
! if input structure not used, do nothing
if ( .not. my_associated( original ) ) return
! create the output structure
call my_create( copy, original%n )
! ...return if no allocation performed
if ( .not. my_associated( copy ) ) return
! copy data
copy%x = original%x
copy%y = original%y
copy%z = original%z
end subroutine my_assign
elemental function my_add( my1, my2 ) result( mysum )
type(my_type), intent(in) :: my1, my2
type(my_type) :: mysum
! copy the first structure
mysum = my1
! and add its components to the second one
mysum%x = mysum%x + my2%x
mysum%y = mysum%y + my2%y
mysum%z = mysum%z + my2%z
end function my_add
end module my_type_define
!<-----end module my_type_define----->
!<-----begin program my_test----->
program my_test
use my_type_define
implicit none
integer, parameter :: n = 3
integer :: i
type(my_type) :: a, b
type(my_type) :: c(n), d(n)
! Scalar test
call my_create(a, 10)
a%x = 1.0
a%y = 2.0
a%z = 3.0
write(*,'(/,"A")')
call my_inspect(a)
b = a
write(*,'(/,"B")')
call my_inspect(b)
a = a + b
write(*,'(/,"A = A + B")')
call my_inspect(a)
call my_destroy(a)
call my_destroy(b)
! Rank-1 test
call my_create(c, 10)
do i = 1, n
c(i)%x = 1.0
c(i)%y = 2.0
c(i)%z = 3.0
write(*,'(/,"C(",i0,")")') i
call my_inspect(c(i))
end do
d = c
do i = 1, n
write(*,'(/,"D(",i0,")")') i
call my_inspect(d(i))
end do
c = c + d ! commenting this line makes memory leaks go away.
do i = 1, n
write(*,'(/,"C(",i0,") + D(",i0,")")') i, i
call my_inspect(c(i))
end do
call my_destroy(c)
call my_destroy(d)
end program my_test
!<-----end program my_test----->
!<-----begin valgrind output----->
==356==
==356== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 17 from 1)
==356== malloc/free: in use at exit: 360 bytes in 9 blocks.
==356== malloc/free: 146 allocs, 137 frees, 225,998 bytes allocated.
==356== For counts of detected errors, rerun with: -v
==356== searching for pointers to 9 not-freed blocks.
==356== checked 70,540 bytes.
==356==
==356== 120 bytes in 3 blocks are definitely lost in loss record 1 of 3
==356== at 0x40053C0: malloc (vg_replace_malloc.c:149)
==356== by 0x804921F: __my_type_define_MOD_my_create (in a.out)
==356== by 0x8048AE0: __my_type_define_MOD_my_assign (in a.out)
==356== by 0x80486C6: __my_type_define_MOD_my_add (in a.out)
==356== by 0x8049E64: MAIN__ (in a.out)
==356== by 0x804A20A: main (fmain.c:21)
==356==
==356==
==356== 120 bytes in 3 blocks are definitely lost in loss record 2 of 3
==356== at 0x40053C0: malloc (vg_replace_malloc.c:149)
==356== by 0x804912A: __my_type_define_MOD_my_create (in a.out)
==356== by 0x8048AE0: __my_type_define_MOD_my_assign (in a.out)
==356== by 0x80486C6: __my_type_define_MOD_my_add (in a.out)
==356== by 0x8049E64: MAIN__ (in a.out)
==356== by 0x804A20A: main (fmain.c:21)
==356==
==356==
==356== 120 bytes in 3 blocks are definitely lost in loss record 3 of 3
==356== at 0x40053C0: malloc (vg_replace_malloc.c:149)
==356== by 0x8049035: __my_type_define_MOD_my_create (in a.out)
==356== by 0x8048AE0: __my_type_define_MOD_my_assign (in a.out)
==356== by 0x80486C6: __my_type_define_MOD_my_add (in a.out)
==356== by 0x8049E64: MAIN__ (in a.out)
==356== by 0x804A20A: main (fmain.c:21)
==356==
==356== LEAK SUMMARY:
==356== definitely lost: 360 bytes in 9 blocks.
==356== possibly lost: 0 bytes in 0 blocks.
==356== still reachable: 0 bytes in 0 blocks.
==356== suppressed: 0 bytes in 0 blocks.
!<-----end valgrind output----->
--
Summary: Memory leakage with allocatables and user-defined
operators
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41936] Memory leakage with allocatables and user-defined operators
2009-11-04 9:01 [Bug fortran/41936] New: " burnus at gcc dot gnu dot org
@ 2009-11-12 13:51 ` pault at gcc dot gnu dot org
0 siblings, 0 replies; 10+ messages in thread
From: pault at gcc dot gnu dot org @ 2009-11-12 13:51 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from pault at gcc dot gnu dot org 2009-11-12 13:50 -------
The testcase segfaults on the a = a + b and the c = c + d on Cygwin. On FC8
i386, valgrind does not show any problem with either and the testprogramme runs
to completion!
However, moving a = a + b to subroutine foo and c = c+ d to subroutine bar
isolates the source of the problem.
bar ()
{
{
integer(kind=4) S.23;
S.23 = 1;
while (1)
{
if (S.23 > 3) goto L.11;
{
struct my_type D.1542;
D.1542 = my_add (&c[S.23 + -1], &d[S.23 + -1]);
my_assign (&c[S.23 + -1], &D.1542);
}
S.23 = S.23 + 1;
}
L.11:;
}
}
foo ()
{
{
struct my_type D.1547;
D.1547 = my_add (&a, &b);
my_assign (&a, &D.1547);
if (D.1547.x.data != 0B)
{
__builtin_free ((void *) D.1547.x.data);
}
D.1547.x.data = 0B;
if (D.1547.y.data != 0B)
{
__builtin_free ((void *) D.1547.y.data);
}
D.1547.y.data = 0B;
if (D.1547.z.data != 0B)
{
__builtin_free ((void *) D.1547.z.data);
}
D.1547.z.data = 0B;
}
}
Most of the right allocating and freeing goes on in 'my_add' and 'my_assign'.
However, whilst 'foo' (scalar) frees the allocatable components of the
temporary D.1547, the same is not true for D.1542 in 'bar' (array).
This loses (n = 3) x (4 bytes) x (3 components) x (dim = 10) = 360 bytes.
The problem, therefore, lies in the scalarization of the elemental call to
'my_add', where the deallocation of the temporary goes walkabout. If I would
hazard a guess, without looking, I would say that the post-block for the scalar
assignment has not been incorporated in the loop body.
Paul
--
pault at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-11-12 13:50:59
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41936
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2014-07-07 14:00 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-41936-4@http.gcc.gnu.org/bugzilla/>
2011-02-28 21:59 ` [Bug fortran/41936] Memory leakage with allocatables and user-defined operators mikael at gcc dot gnu.org
2014-04-27 14:05 ` dominiq at lps dot ens.fr
2014-04-27 14:32 ` burnus at gcc dot gnu.org
2014-04-27 14:47 ` dominiq at lps dot ens.fr
2014-05-04 10:06 ` dominiq at lps dot ens.fr
2014-06-10 11:43 ` dominiq at gcc dot gnu.org
2014-07-07 12:33 ` dominiq at gcc dot gnu.org
2014-07-07 14:00 ` dominiq at lps dot ens.fr
2014-07-07 14:00 ` dominiq at lps dot ens.fr
2009-11-04 9:01 [Bug fortran/41936] New: " burnus at gcc dot gnu dot org
2009-11-12 13:51 ` [Bug fortran/41936] " pault at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).