public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/58229] New: Memory leak with overloaded operator
@ 2013-08-23 9:30 jwmwalrus at gmail dot com
2013-08-23 16:05 ` [Bug fortran/58229] [F03] Memory leak with allocatable function result janus at gcc dot gnu.org
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: jwmwalrus at gmail dot com @ 2013-08-23 9:30 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58229
Bug ID: 58229
Summary: Memory leak with overloaded operator
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: jwmwalrus at gmail dot com
The following, reduced version of the actual code (sorry if it's still too
big), leaks memory quite fast when compiled with gfortran 4.8/4.9:
!gfortran-4.9 -o test_leak ~/test_leak.f90
module mod1
implicit none
type :: pointtype
real :: x = 0, y = 0, z = 0
end type
interface operator(*)
module procedure point_times_scalar
module procedure scalar_times_point
end interface
contains
elemental function point_times_scalar(point, scalar) result(res)
!type(pointtype) :: res
type(pointtype), allocatable :: res
type(pointtype), intent(IN) :: point
real, intent(IN) :: scalar
res = pointtype(point%x * scalar, point%y * scalar, point%z * scalar)
end function
elemental function scalar_times_point(scalar, point) result(res)
!type(pointtype) :: res
type(pointtype), allocatable :: res
real, intent(IN) :: scalar
type(pointtype), intent(IN) :: point
res = point * scalar
end function
end module mod1
use mod1
implicit none
integer :: i, j
real :: x(3)
type(pointtype), allocatable :: a(:,:)
allocate (a(100,100))
do j = 1, SIZE(a,2)
do i = 1, SIZE(a, 1)
call RANDOM_NUMBER(x)
a(i,j) = pointtype(x(1), x(2), x(3))
a(i,j) = 2. * a(i,j)
a(i,j) = 3. * a(i,j)
a(i,j) = 4. * a(i,j)
enddo
enddo
end
Version 4.9 seems to be leaking more memory than version 4.8. Valgrind's
output is:
==10718== Memcheck, a memory error detector
==10718== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==10718== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==10718== Command: ./test_leak
==10718== Parent PID: 31089
==10718==
--10718--
--10718-- Valgrind options:
--10718-- --suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp
--10718-- -v
--10718-- --log-file=./valgrind.log
--10718-- --num-callers=100
--10718-- --leak-check=full
--10718-- --undef-value-errors=no
--10718-- Contents of /proc/version:
--10718-- Linux version 3.10-2-amd64 (debian-kernel@lists.debian.org) (gcc
version 4.7.3 (Debian 4.7.3-6) ) #1 SMP Debian 3.10.5-1 (2013-08-07)
--10718-- Arch and hwcaps: AMD64, amd64-sse3-cx16-lzcnt
--10718-- Page sizes: currently 4096, max supported 4096
--10718-- Valgrind library directory: /usr/lib/valgrind
--10718-- Reading syms from /tmp/test_leak
--10718-- Reading syms from /lib/x86_64-linux-gnu/ld-2.17.so
--10718-- Considering /lib/x86_64-linux-gnu/ld-2.17.so ..
--10718-- .. CRC mismatch (computed 1a41d356 wanted 031d690d)
--10718-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.17.so ..
--10718-- .. CRC is valid
--10718-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux
--10718-- Considering /usr/lib/valgrind/memcheck-amd64-linux ..
--10718-- .. CRC mismatch (computed 5a0963b7 wanted f2a7ec16)
--10718-- Considering /usr/lib/debug/usr/lib/valgrind/memcheck-amd64-linux ..
--10718-- .. CRC is valid
--10718-- object doesn't have a dynamic symbol table
--10718-- Scheduler: using generic scheduler lock implementation.
--10718-- Reading suppressions file: /usr/lib/valgrind/debian-libc6-dbg.supp
--10718-- Reading suppressions file: /usr/lib/valgrind/default.supp
==10718== embedded gdbserver: reading from
/tmp/vgdb-pipe-from-vgdb-to-10718-by-jwm-on-???
==10718== embedded gdbserver: writing to
/tmp/vgdb-pipe-to-vgdb-from-10718-by-jwm-on-???
==10718== embedded gdbserver: shared mem
/tmp/vgdb-pipe-shared-mem-vgdb-10718-by-jwm-on-???
==10718==
==10718== TO CONTROL THIS PROCESS USING vgdb (which you probably
==10718== don't want to do, unless you know exactly what you're doing,
==10718== or are doing some strange experiment):
==10718== /usr/lib/valgrind/../../bin/vgdb --pid=10718 ...command...
==10718==
==10718== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==10718== /path/to/gdb ./test_leak
==10718== and then give GDB the following command
==10718== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=10718
==10718== --pid is optional if only one valgrind process is running
==10718==
--10718-- REDIR: 0x4017870 (strlen) redirected to 0x3806e381
(vgPlain_amd64_linux_REDIR_FOR_strlen)
--10718-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so
--10718-- Considering /usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--10718-- .. CRC mismatch (computed 2f3ef0a4 wanted fa342ee8)
--10718-- Considering
/usr/lib/debug/usr/lib/valgrind/vgpreload_core-amd64-linux.so ..
--10718-- .. CRC is valid
--10718-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so
--10718-- Considering /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--10718-- .. CRC mismatch (computed 9eb41274 wanted 68f65041)
--10718-- Considering
/usr/lib/debug/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so ..
--10718-- .. CRC is valid
--10718-- REDIR: 0x40176e0 (index) redirected to 0x4c2c500 (index)
--10718-- REDIR: 0x4017760 (strcmp) redirected to 0x4c2d5e0 (strcmp)
--10718-- Reading syms from /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0
--10718-- Considering /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0 ..
--10718-- .. CRC mismatch (computed 10620798 wanted 7bdb0a8c)
--10718-- object doesn't have a symbol table
--10718-- Reading syms from /lib/x86_64-linux-gnu/libm-2.17.so
--10718-- Considering /lib/x86_64-linux-gnu/libm-2.17.so ..
--10718-- .. CRC mismatch (computed f2860654 wanted 54fdd28f)
--10718-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.17.so ..
--10718-- .. CRC is valid
--10718-- Reading syms from /lib/x86_64-linux-gnu/libgcc_s.so.1
--10718-- Considering /lib/x86_64-linux-gnu/libgcc_s.so.1 ..
--10718-- .. CRC mismatch (computed a7742875 wanted cd71ce72)
--10718-- object doesn't have a symbol table
--10718-- Reading syms from /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0
--10718-- Considering /usr/lib/x86_64-linux-gnu/libquadmath.so.0.0.0 ..
--10718-- .. CRC mismatch (computed ef8c21b4 wanted 2a9b3184)
--10718-- object doesn't have a symbol table
--10718-- Reading syms from /lib/x86_64-linux-gnu/libc-2.17.so
--10718-- Considering /lib/x86_64-linux-gnu/libc-2.17.so ..
--10718-- .. CRC mismatch (computed 426a2978 wanted 1dd0f5ac)
--10718-- Considering /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.17.so ..
--10718-- .. CRC is valid
--10718-- REDIR: 0x5920da0 (strcasecmp) redirected to 0x4a24720
(_vgnU_ifunc_wrapper)
--10718-- REDIR: 0x591d160 (strnlen) redirected to 0x4a24720
(_vgnU_ifunc_wrapper)
--10718-- REDIR: 0x5923070 (strncasecmp) redirected to 0x4a24720
(_vgnU_ifunc_wrapper)
--10718-- REDIR: 0x591fbb0 (memset) redirected to 0x4a24720
(_vgnU_ifunc_wrapper)
--10718-- REDIR: 0x591fb60 (memcpy@GLIBC_2.2.5) redirected to 0x4a24720
(_vgnU_ifunc_wrapper)
--10718-- REDIR: 0x591eb50 (__GI_strrchr) redirected to 0x4c2c320
(__GI_strrchr)
--10718-- REDIR: 0x5917990 (calloc) redirected to 0x4c2b490 (calloc)
--10718-- REDIR: 0x5917030 (malloc) redirected to 0x4c292f0 (malloc)
--10718-- REDIR: 0x591d080 (__GI_strlen) redirected to 0x4c2c8b0 (__GI_strlen)
--10718-- REDIR: 0x591d030 (strlen) redirected to 0x4a24720
(_vgnU_ifunc_wrapper)
--10718-- REDIR: 0x5925750 (memcpy@@GLIBC_2.14) redirected to 0x4a24720
(_vgnU_ifunc_wrapper)
--10718-- REDIR: 0x59257a0 (__GI_memcpy) redirected to 0x4c2d930
(memcpy@@GLIBC_2.14)
--10718-- REDIR: 0x591d280 (__GI_strncmp) redirected to 0x4c2cda0
(__GI_strncmp)
--10718-- REDIR: 0x5917450 (free) redirected to 0x4c2a620 (free)
==10718==
==10718== HEAP SUMMARY:
==10718== in use at exit: 840,000 bytes in 60,001 blocks
==10718== total heap usage: 60,022 allocs, 21 frees, 851,799 bytes allocated
==10718==
==10718== Searching for pointers to 60,001 not-freed blocks
==10718== Checked 99,896 bytes
==10718==
==10718== 120,000 bytes in 1 blocks are definitely lost in loss record 1 of 7
==10718== at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10718== by 0x4009A1: MAIN__ (in /tmp/test_leak)
==10718== by 0x400DB7: main (in /tmp/test_leak)
==10718==
==10718== 120,000 bytes in 10,000 blocks are definitely lost in loss record 2
of 7
==10718== at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10718== by 0x400855: __mod1_MOD_scalar_times_point (in /tmp/test_leak)
==10718== by 0x400C29: MAIN__ (in /tmp/test_leak)
==10718== by 0x400DB7: main (in /tmp/test_leak)
==10718==
==10718== 120,000 bytes in 10,000 blocks are definitely lost in loss record 3
of 7
==10718== at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10718== by 0x4008B3: __mod1_MOD_point_times_scalar (in /tmp/test_leak)
==10718== by 0x40086C: __mod1_MOD_scalar_times_point (in /tmp/test_leak)
==10718== by 0x400C29: MAIN__ (in /tmp/test_leak)
==10718== by 0x400DB7: main (in /tmp/test_leak)
==10718==
==10718== 120,000 bytes in 10,000 blocks are definitely lost in loss record 4
of 7
==10718== at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10718== by 0x400855: __mod1_MOD_scalar_times_point (in /tmp/test_leak)
==10718== by 0x400CA8: MAIN__ (in /tmp/test_leak)
==10718== by 0x400DB7: main (in /tmp/test_leak)
==10718==
==10718== 120,000 bytes in 10,000 blocks are definitely lost in loss record 5
of 7
==10718== at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10718== by 0x4008B3: __mod1_MOD_point_times_scalar (in /tmp/test_leak)
==10718== by 0x40086C: __mod1_MOD_scalar_times_point (in /tmp/test_leak)
==10718== by 0x400CA8: MAIN__ (in /tmp/test_leak)
==10718== by 0x400DB7: main (in /tmp/test_leak)
==10718==
==10718== 120,000 bytes in 10,000 blocks are definitely lost in loss record 6
of 7
==10718== at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10718== by 0x400855: __mod1_MOD_scalar_times_point (in /tmp/test_leak)
==10718== by 0x400D27: MAIN__ (in /tmp/test_leak)
==10718== by 0x400DB7: main (in /tmp/test_leak)
==10718==
==10718== 120,000 bytes in 10,000 blocks are definitely lost in loss record 7
of 7
==10718== at 0x4C2935B: malloc (vg_replace_malloc.c:270)
==10718== by 0x4008B3: __mod1_MOD_point_times_scalar (in /tmp/test_leak)
==10718== by 0x40086C: __mod1_MOD_scalar_times_point (in /tmp/test_leak)
==10718== by 0x400D27: MAIN__ (in /tmp/test_leak)
==10718== by 0x400DB7: main (in /tmp/test_leak)
==10718==
==10718== LEAK SUMMARY:
==10718== definitely lost: 840,000 bytes in 60,001 blocks
==10718== indirectly lost: 0 bytes in 0 blocks
==10718== possibly lost: 0 bytes in 0 blocks
==10718== still reachable: 0 bytes in 0 blocks
==10718== suppressed: 0 bytes in 0 blocks
==10718==
==10718== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)
==10718== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 0 from 0)
And the system info is:
...:/tmp$ ll `which gfortran-4.9` && /usr/lib/gcc-snapshot/bin/gfortran -v &&
apt-cache policy gfortran-4.8 gcc-snapshot && lsb_release -rd
lrwxrwxrwx 1 root staff 35 Aug 17 21:16 /usr/local/bin/gfortran-4.9 ->
../../lib/gcc-snapshot/bin/gfortran*
Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20130821-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-snap-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --disable-werror
--enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.0 20130821 (experimental) [trunk revision 201901] (Debian
20130821-1)
gfortran-4.8:
Installed: 4.8.1-9
Candidate: 4.8.1-9
Version table:
*** 4.8.1-9 0
200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
4.8.1-2 0
500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages
gcc-snapshot:
Installed: 20130821-1
Candidate: 20130821-1
Version table:
*** 20130821-1 0
200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages
100 /var/lib/dpkg/status
Description: Debian GNU/Linux testing (jessie)
Release: testing
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/58229] [F03] Memory leak with allocatable function result
2013-08-23 9:30 [Bug fortran/58229] New: Memory leak with overloaded operator jwmwalrus at gmail dot com
@ 2013-08-23 16:05 ` janus at gcc dot gnu.org
2013-08-24 9:22 ` janus at gcc dot gnu.org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: janus at gcc dot gnu.org @ 2013-08-23 16:05 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58229
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-08-23
CC| |janus at gcc dot gnu.org
Summary|Memory leak with overloaded |[F03] Memory leak with
|operator |allocatable function result
Ever confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu.org ---
Confirmed. Reduced test case:
implicit none
type :: pointtype
real :: x = 0, y = 0, z = 0
end type
integer :: i, j
real :: x(3)
type(pointtype), allocatable :: a(:,:)
allocate (a(10,10))
do j = 1, SIZE(a,2)
do i = 1, SIZE(a, 1)
call RANDOM_NUMBER(x)
a(i,j) = pointtype(x(1), x(2), x(3))
a(i,j) = scalar_times_point (2. , a(i,j))
enddo
enddo
contains
function scalar_times_point(scalar, point) result(res)
type(pointtype), allocatable :: res
real, intent(IN) :: scalar
type(pointtype), intent(IN) :: point
res = pointtype(point%x * scalar, point%y * scalar, point%z * scalar)
end function
end
It is not really connected to operators, but rather to allocatable function
results in general. The variant above shows two leaks with 4.9 trunk:
==31477== 1,200 bytes in 1 blocks are definitely lost in loss record 1 of 2
==31477== at 0x4C2C27B: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31477== by 0x400986: MAIN__ (c0.f90:11)
==31477== by 0x400C9E: main (c0.f90:13)
==31477==
==31477== 1,200 bytes in 100 blocks are definitely lost in loss record 2 of 2
==31477== at 0x4C2C27B: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31477== by 0x400898: scalar_times_point.1878 (c0.f90:27)
==31477== by 0x400C0E: MAIN__ (c0.f90:17)
==31477== by 0x400C9E: main (c0.f90:13)
The first one is the ALLOCATE in the main program, which (according to F08) is
*not* required to be auto-deallocated (4.8 does it, but 4.9 doesn't, so this
explains the difference between the two). This is not a bug.
The second one is the allocate-on-assignment inside the function, which nevers
gets freed. This *is* a bug. What should be done is: Create a temporary for the
function result and free it after the call. This is also one of the cases where
finalization still needs to be handled (cf. PR 37336).
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/58229] [F03] Memory leak with allocatable function result
2013-08-23 9:30 [Bug fortran/58229] New: Memory leak with overloaded operator jwmwalrus at gmail dot com
2013-08-23 16:05 ` [Bug fortran/58229] [F03] Memory leak with allocatable function result janus at gcc dot gnu.org
@ 2013-08-24 9:22 ` janus at gcc dot gnu.org
2013-08-24 10:04 ` [Bug fortran/58229] [F03] Memory leak with allocatable scalar " janus at gcc dot gnu.org
2013-08-25 14:46 ` burnus at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: janus at gcc dot gnu.org @ 2013-08-24 9:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58229
--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
> The second one is the allocate-on-assignment inside the function, which
> nevers gets freed. This *is* a bug. What should be done is: Create a
> temporary for the function result and free it after the call.
This probably needs to happen inside gfc_conv_procedure_call (trans-expr.c).
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/58229] [F03] Memory leak with allocatable scalar function result
2013-08-23 9:30 [Bug fortran/58229] New: Memory leak with overloaded operator jwmwalrus at gmail dot com
2013-08-23 16:05 ` [Bug fortran/58229] [F03] Memory leak with allocatable function result janus at gcc dot gnu.org
2013-08-24 9:22 ` janus at gcc dot gnu.org
@ 2013-08-24 10:04 ` janus at gcc dot gnu.org
2013-08-25 14:46 ` burnus at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: janus at gcc dot gnu.org @ 2013-08-24 10:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58229
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[F03] Memory leak with |[F03] Memory leak with
|allocatable function result |allocatable scalar function
| |result
--- Comment #3 from janus at gcc dot gnu.org ---
As the following test case demonstrates, the leak actually only happens for
allocatable *scalar* results. Array results already get a temporary, which is
passed as argument and deallocated after the call.
implicit none
integer :: i, arr(1:3)
i = alloc_result_scalar ()
arr = alloc_result_array ()
contains
function alloc_result_scalar () result(res)
integer, allocatable :: res
allocate(res)
res = 42
end function
function alloc_result_array () result(res)
integer, dimension(:), allocatable :: res
allocate(res(1:3))
res = (/ 41, 42, 43 /)
end function
end
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug fortran/58229] [F03] Memory leak with allocatable scalar function result
2013-08-23 9:30 [Bug fortran/58229] New: Memory leak with overloaded operator jwmwalrus at gmail dot com
` (2 preceding siblings ...)
2013-08-24 10:04 ` [Bug fortran/58229] [F03] Memory leak with allocatable scalar " janus at gcc dot gnu.org
@ 2013-08-25 14:46 ` burnus at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-08-25 14:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58229
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |burnus at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #4 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Duplicate of PR55603 (or PR46487).
*** This bug has been marked as a duplicate of bug 55603 ***
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-08-25 14:46 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-23 9:30 [Bug fortran/58229] New: Memory leak with overloaded operator jwmwalrus at gmail dot com
2013-08-23 16:05 ` [Bug fortran/58229] [F03] Memory leak with allocatable function result janus at gcc dot gnu.org
2013-08-24 9:22 ` janus at gcc dot gnu.org
2013-08-24 10:04 ` [Bug fortran/58229] [F03] Memory leak with allocatable scalar " janus at gcc dot gnu.org
2013-08-25 14:46 ` 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).