public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
@ 2015-05-11 10:51 ` rguenth at gcc dot gnu.org
2015-05-16 8:24 ` pault at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-05-11 10:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |6.0
Summary|[6.0 Regression] memory |[6 Regression] memory leak
|leak with source allocation |with source allocation in
|in internal subprogram |internal subprogram
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
2015-05-11 10:51 ` [Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram rguenth at gcc dot gnu.org
@ 2015-05-16 8:24 ` pault at gcc dot gnu.org
2015-05-16 15:32 ` pault at gcc dot gnu.org
` (11 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: pault at gcc dot gnu.org @ 2015-05-16 8:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2015-05-16
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> ---
Hi Damian,
The reason for this memory leak is rather obvious:
newrealvec ()
{
struct subdata * d;
try
{
d = 0B;
{
struct subdata D.3386;
struct subdata D.3385;
struct subdata subdata.0;
subdata.0.b = (integer(kind=4) *) __builtin_malloc (4);
*subdata.0.b = 0;
D.3385 = subdata.0;
D.3386 = D.3385;
if (d != 0B)
{
_gfortran_runtime_error_at (&"At line 10 of file
pr66079.f90"[1]{lb: 1 sz: 1}, &"Attempting to allocate already allocated
variable \'%s\'"[1]{lb: 1 sz: 1}, &"d"[1]{lb: 1 sz: 1});
}
else
{
d = (struct subdata *) __builtin_malloc (8);
if (d == 0B)
{
_gfortran_os_error (&"Allocation would exceed memory
limit"[1]{lb: 1 sz: 1});
}
}
d->b = 0B;
{
struct subdata subdata.1;
subdata.1.b = (integer(kind=4) *) __builtin_malloc (4);
*subdata.1.b = 0;
*d = subdata.1;
}
}
}
finally
{
if (d != 0B)
{
if (d->b != 0B)
{
__builtin_free ((void *) d->b);
}
d->b = 0B;
__builtin_free ((void *) d);
}
}
}
subdata.1 gets freed in the finally block but subdata.0, which is redundant in
any case, does not.
Confirmed - thanks for the report.... I just have to find out why it is we wind
up with two subdata's.
Cheers
Paul
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
2015-05-11 10:51 ` [Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram rguenth at gcc dot gnu.org
2015-05-16 8:24 ` pault at gcc dot gnu.org
@ 2015-05-16 15:32 ` pault at gcc dot gnu.org
2015-05-18 1:36 ` damian at sourceryinstitute dot org
` (10 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: pault at gcc dot gnu.org @ 2015-05-16 15:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 35555
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35555&action=edit
Initial fix
This is a partial fix, in that it deals with the initial problem.
type subdata
integer, allocatable :: b
endtype
block
call newRealVec
end block
contains
subroutine newRealVec
type(subdata), allocatable :: d, e, f
allocate(d,source=subdata(1)) ! was lost, now OK
allocate(e,source=d) ! OK
allocate(f,source=create (99)) ! 8 bytes go AWOL
if (d%b .ne. 1) call abort
if (e%b .ne. 1) call abort
if (f%b .ne. 99) call abort
f = create (42) ! another 8 bytes go AWOL
print *, f%b
end subroutine
function create (arg) result(res)
integer :: arg
type(subdata), allocatable :: res
allocate(res, source = subdata(arg))
end function
end
The function calls are losing the allocation for the subdata type itself. The b
component is correctly dealt with. I know what has to be done to fix this.
Arrays are a mess.
allocate (d(2), source = subdata ()) ICEs on a double free
allocate (d(2), source = [subdata (1), subdata (2)]) loses 8 bytes in two
chunks.
Watch this space.
Paul
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2015-05-16 15:32 ` pault at gcc dot gnu.org
@ 2015-05-18 1:36 ` damian at sourceryinstitute dot org
2015-05-21 4:25 ` pault at gcc dot gnu.org
` (9 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: damian at sourceryinstitute dot org @ 2015-05-18 1:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
--- Comment #3 from Damian Rouson <damian at sourceryinstitute dot org> ---
Thanks for working on this.
Damian
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2015-05-18 1:36 ` damian at sourceryinstitute dot org
@ 2015-05-21 4:25 ` pault at gcc dot gnu.org
2015-05-22 22:57 ` pault at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: pault at gcc dot gnu.org @ 2015-05-21 4:25 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
--- Comment #4 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 35583
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35583&action=edit
Further advanced patch
This version fixes non-character allocatable scalar functions. Now, only
allocatable character functions leak memory.
Paul
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2015-05-21 4:25 ` pault at gcc dot gnu.org
@ 2015-05-22 22:57 ` pault at gcc dot gnu.org
2015-06-11 15:50 ` pault at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: pault at gcc dot gnu.org @ 2015-05-22 22:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
--- Comment #5 from Paul Thomas <pault at gcc dot gnu.org> ---
Created attachment 35603
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35603&action=edit
Nearly OK patch
The attached bootstraps and regtests on 6.0.0. The following runs without
memory leaks and fixes problems as indicated:
type subdata
integer, allocatable :: b
endtype
! block
call newRealVec
! end block
contains
subroutine newRealVec
type(subdata), allocatable :: d, e, f
character(:), allocatable :: g, h, i
allocate(d,source=subdata(1)) ! memory was lost, now OK
allocate(e,source=d) ! OK
allocate(f,source=create (99)) ! memory was lost, now OK
if (d%b .ne. 1) call abort
if (e%b .ne. 1) call abort
if (f%b .ne. 99) call abort
allocate (g, source = greeting1("good day"))
if (g .ne. "good day") call abort
allocate (h, source = greeting2("hello"))
if (h .ne. "hello") call abort
allocate (i, source = greeting3("hiya!"))
if (i .ne. "hiya!") call abort
end subroutine
function create (arg) result(res)
integer :: arg
type(subdata), allocatable :: res
allocate(res, source = subdata(arg))
end function
function greeting1 (arg) result(res) ! memory was lost, now OK
character(*) :: arg
Character(:), allocatable :: res
allocate(res, source = arg)
end function
function greeting2 (arg) result(res)
character(5) :: arg
Character(:), allocatable :: res
allocate(res, source = arg)
end function
function greeting3 (arg) result(res)
character(5) :: arg
Character(5), allocatable :: res, res1
allocate(res, source = arg) ! Caused an ICE - now OK
allocate(res1, source = arg) ! Caused an ICE - now OK
if (res1 .ne. res) call abort
end function
end
Just a small amount of cleaning up to do before submission.
Paul
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
` (5 preceding siblings ...)
2015-05-22 22:57 ` pault at gcc dot gnu.org
@ 2015-06-11 15:50 ` pault at gcc dot gnu.org
2015-06-13 0:21 ` damian at sourceryinstitute dot org
` (6 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: pault at gcc dot gnu.org @ 2015-06-11 15:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
--- Comment #6 from Paul Thomas <pault at gcc dot gnu.org> ---
Author: pault
Date: Thu Jun 11 15:49:32 2015
New Revision: 224383
URL: https://gcc.gnu.org/viewcvs?rev=224383&root=gcc&view=rev
Log:
2015-06-11 Paul Thomas <pault@gcc.gnu.org>
PR fortran/66079
* trans-expr.c (gfc_conv_procedure_call): Allocatable scalar
function results must be freed and nullified after use. Create
a temporary to hold the result to prevent duplicate calls.
* trans-stmt.c (gfc_trans_allocate): Rename temporary variable
as 'source'. Deallocate allocatable components of non-variable
'source's.
2015-06-11 Paul Thomas <pault@gcc.gnu.org>
PR fortran/66079
* gfortran.dg/allocatable_scalar_13.f90: New test
Added:
trunk/gcc/testsuite/gfortran.dg/allocatable_scalar_13.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-expr.c
trunk/gcc/fortran/trans-stmt.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
` (6 preceding siblings ...)
2015-06-11 15:50 ` pault at gcc dot gnu.org
@ 2015-06-13 0:21 ` damian at sourceryinstitute dot org
2015-08-04 9:27 ` mikael at gcc dot gnu.org
` (5 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: damian at sourceryinstitute dot org @ 2015-06-13 0:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
--- Comment #7 from Damian Rouson <damian at sourceryinstitute dot org> ---
Thanks for the fix! I'll update my source, rebuild, and test the fix.
Damian
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
` (7 preceding siblings ...)
2015-06-13 0:21 ` damian at sourceryinstitute dot org
@ 2015-08-04 9:27 ` mikael at gcc dot gnu.org
2015-08-04 9:32 ` paul.richard.thomas at gmail dot com
` (4 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: mikael at gcc dot gnu.org @ 2015-08-04 9:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikael at gcc dot gnu.org
--- Comment #10 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to Paul Thomas from comment #8)
> Created attachment 36113 [details]
> Patch for th 5 branch
>
Doesn't look like a patch. :-/
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
` (8 preceding siblings ...)
2015-08-04 9:27 ` mikael at gcc dot gnu.org
@ 2015-08-04 9:32 ` paul.richard.thomas at gmail dot com
2015-10-16 8:34 ` [Bug fortran/66079] [5 " rguenth at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: paul.richard.thomas at gmail dot com @ 2015-08-04 9:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
--- Comment #11 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Hi Mikael,
It looks like my finger slipped on the mouse wheel - I'll put it right tonight.
Thanks
Paul
On 4 August 2015 at 11:27, mikael at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
>
> Mikael Morin <mikael at gcc dot gnu.org> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> CC| |mikael at gcc dot gnu.org
>
> --- Comment #10 from Mikael Morin <mikael at gcc dot gnu.org> ---
> (In reply to Paul Thomas from comment #8)
>> Created attachment 36113 [details]
>> Patch for th 5 branch
>>
> Doesn't look like a patch. :-/
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/66079] [5 Regression] memory leak with source allocation in internal subprogram
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
` (10 preceding siblings ...)
2015-10-16 8:34 ` [Bug fortran/66079] [5 " rguenth at gcc dot gnu.org
@ 2015-10-16 8:34 ` rguenth at gcc dot gnu.org
2015-10-18 18:37 ` pault at gcc dot gnu.org
2015-10-18 19:43 ` pault at gcc dot gnu.org
13 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-10-16 8:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P4
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/66079] [5 Regression] memory leak with source allocation in internal subprogram
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
` (9 preceding siblings ...)
2015-08-04 9:32 ` paul.richard.thomas at gmail dot com
@ 2015-10-16 8:34 ` rguenth at gcc dot gnu.org
2015-10-16 8:34 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 14+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-10-16 8:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|6.0 |5.3
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/66079] [5 Regression] memory leak with source allocation in internal subprogram
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
` (11 preceding siblings ...)
2015-10-16 8:34 ` rguenth at gcc dot gnu.org
@ 2015-10-18 18:37 ` pault at gcc dot gnu.org
2015-10-18 19:43 ` pault at gcc dot gnu.org
13 siblings, 0 replies; 14+ messages in thread
From: pault at gcc dot gnu.org @ 2015-10-18 18:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
--- Comment #12 from Paul Thomas <pault at gcc dot gnu.org> ---
Author: pault
Date: Sun Oct 18 18:36:52 2015
New Revision: 228952
URL: https://gcc.gnu.org/viewcvs?rev=228952&root=gcc&view=rev
Log:
2015-10-18 Paul Thomas <pault@gcc.gnu.org>
PR fortran/66079
* trans-expr.c (gfc_conv_procedure_call): Allocatable scalar
function results must be freed and nullified after use. Create
a temporary to hold the result to prevent duplicate calls.
* trans-stmt.c (gfc_trans_allocate): Rename temporary variable
as 'source'. Deallocate allocatable components of non-variable
'source's.
2015-10-18 Paul Thomas <pault@gcc.gnu.org>
PR fortran/66079
* gfortran.dg/allocatable_scalar_13.f90: New test
Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/allocatable_scalar_13.f90
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/trans-expr.c
branches/gcc-5-branch/gcc/fortran/trans-stmt.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug fortran/66079] [5 Regression] memory leak with source allocation in internal subprogram
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
` (12 preceding siblings ...)
2015-10-18 18:37 ` pault at gcc dot gnu.org
@ 2015-10-18 19:43 ` pault at gcc dot gnu.org
13 siblings, 0 replies; 14+ messages in thread
From: pault at gcc dot gnu.org @ 2015-10-18 19:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66079
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #13 from Paul Thomas <pault at gcc dot gnu.org> ---
Closing after commits to trunk and 5 branch.
Thanks for the report.
Paul
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2015-10-18 19:43 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-66079-4@http.gcc.gnu.org/bugzilla/>
2015-05-11 10:51 ` [Bug fortran/66079] [6 Regression] memory leak with source allocation in internal subprogram rguenth at gcc dot gnu.org
2015-05-16 8:24 ` pault at gcc dot gnu.org
2015-05-16 15:32 ` pault at gcc dot gnu.org
2015-05-18 1:36 ` damian at sourceryinstitute dot org
2015-05-21 4:25 ` pault at gcc dot gnu.org
2015-05-22 22:57 ` pault at gcc dot gnu.org
2015-06-11 15:50 ` pault at gcc dot gnu.org
2015-06-13 0:21 ` damian at sourceryinstitute dot org
2015-08-04 9:27 ` mikael at gcc dot gnu.org
2015-08-04 9:32 ` paul.richard.thomas at gmail dot com
2015-10-16 8:34 ` [Bug fortran/66079] [5 " rguenth at gcc dot gnu.org
2015-10-16 8:34 ` rguenth at gcc dot gnu.org
2015-10-18 18:37 ` pault at gcc dot gnu.org
2015-10-18 19:43 ` pault 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).