public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [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.
@ 2012-05-17 16:37 stephan.kramer at imperial dot ac.uk
2012-05-17 17:26 ` [Bug fortran/53389] " kargl at gcc dot gnu.org
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: stephan.kramer at imperial dot ac.uk @ 2012-05-17 16:37 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [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.
2012-05-17 16:37 [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
@ 2012-05-17 17:26 ` kargl at gcc dot gnu.org
2012-05-18 9:22 ` [Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: " burnus at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: kargl at gcc dot gnu.org @ 2012-05-17 17:26 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [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
2012-05-17 16:37 [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
2012-05-17 17:26 ` [Bug fortran/53389] " kargl at gcc dot gnu.org
@ 2012-05-18 9:22 ` burnus at gcc dot gnu.org
2012-05-18 17:37 ` stephan.kramer at imperial dot ac.uk
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-05-18 9:22 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [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
2012-05-17 16:37 [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
2012-05-17 17:26 ` [Bug fortran/53389] " kargl at gcc dot gnu.org
2012-05-18 9:22 ` [Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: " burnus at gcc dot gnu.org
@ 2012-05-18 17:37 ` stephan.kramer at imperial dot ac.uk
2012-05-18 17:45 ` burnus at gcc dot gnu.org
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: stephan.kramer at imperial dot ac.uk @ 2012-05-18 17:37 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [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
2012-05-17 16:37 [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
` (2 preceding siblings ...)
2012-05-18 17:37 ` stephan.kramer at imperial dot ac.uk
@ 2012-05-18 17:45 ` burnus at gcc dot gnu.org
2012-05-21 17:58 ` burnus at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-05-18 17:45 UTC (permalink / raw)
To: gcc-bugs
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);
^ permalink raw reply [flat|nested] 10+ messages in thread
* [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
2012-05-17 16:37 [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
` (3 preceding siblings ...)
2012-05-18 17:45 ` burnus at gcc dot gnu.org
@ 2012-05-21 17:58 ` burnus at gcc dot gnu.org
2012-05-22 10:13 ` burnus at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-05-21 17:58 UTC (permalink / raw)
To: gcc-bugs
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,
^ permalink raw reply [flat|nested] 10+ messages in thread
* [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
2012-05-17 16:37 [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
` (4 preceding siblings ...)
2012-05-21 17:58 ` burnus at gcc dot gnu.org
@ 2012-05-22 10:13 ` burnus at gcc dot gnu.org
2012-05-23 19:14 ` burnus at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-05-22 10:13 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [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
2012-05-17 16:37 [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
` (5 preceding siblings ...)
2012-05-22 10:13 ` burnus at gcc dot gnu.org
@ 2012-05-23 19:14 ` burnus at gcc dot gnu.org
2012-05-23 19:15 ` burnus at gcc dot gnu.org
2012-05-23 19:29 ` burnus at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-05-23 19:14 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [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
2012-05-17 16:37 [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
` (6 preceding siblings ...)
2012-05-23 19:14 ` burnus at gcc dot gnu.org
@ 2012-05-23 19:15 ` burnus at gcc dot gnu.org
2012-05-23 19:29 ` burnus at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-05-23 19:15 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [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
2012-05-17 16:37 [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
` (7 preceding siblings ...)
2012-05-23 19:15 ` burnus at gcc dot gnu.org
@ 2012-05-23 19:29 ` burnus at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2012-05-23 19:29 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2012-05-23 19:15 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-05-17 16:37 [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
2012-05-17 17:26 ` [Bug fortran/53389] " kargl at gcc dot gnu.org
2012-05-18 9:22 ` [Bug fortran/53389] [4.6/4.7/4.8 Regression] -frealloc-lhs: " burnus at gcc dot gnu.org
2012-05-18 17:37 ` stephan.kramer at imperial dot ac.uk
2012-05-18 17:45 ` burnus at gcc dot gnu.org
2012-05-21 17:58 ` burnus at gcc dot gnu.org
2012-05-22 10:13 ` burnus at gcc dot gnu.org
2012-05-23 19:14 ` burnus at gcc dot gnu.org
2012-05-23 19:15 ` burnus at gcc dot gnu.org
2012-05-23 19:29 ` burnus at gcc dot gnu.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).