https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473
Bug ID: 63473
Summary: Memory leak with ALLOCATABLE, INTENT(OUT) dummy
arguments.
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: paul.vandelst at noaa dot gov
Created attachment 33659
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33659&action=edit
Test program that exhibits the memory leak issue.
I'm seeing the following valgrind output from the attached test program using
gfortran 4.8.2 and 4.9.2:
$ gfortran -g test_allocarg.f90
$ valgrind --leak-check=full ./a.out
==13675== Memcheck, a memory error detector
==13675== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==13675== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==13675== Command: ./a.out
==13675==
F
T
T
==13675==
==13675== HEAP SUMMARY:
==13675== in use at exit: 2,160 bytes in 61 blocks
==13675== total heap usage: 80 allocs, 19 frees, 7,774 bytes allocated
==13675==
==13675== 800 bytes in 40 blocks are definitely lost in loss record 2 of 3
==13675== at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==13675== by 0x400CF0: __testmodule_MOD_create_mytype (test_allocarg.f90:15)
==13675== by 0x400B74: __testmodule_MOD_allocate_mytype
(test_allocarg.f90:24)
==13675== by 0x400E47: MAIN__ (test_allocarg.f90:40)
==13675== by 0x400E94: main (test_allocarg.f90:33)
==13675==
==13675== 1,360 (960 direct, 400 indirect) bytes in 1 blocks are definitely
lost in loss record 3 of 3
==13675== at 0x4A069EE: malloc (vg_replace_malloc.c:270)
==13675== by 0x4009DA: __testmodule_MOD_allocate_mytype
(test_allocarg.f90:22)
==13675== by 0x400E47: MAIN__ (test_allocarg.f90:40)
==13675== by 0x400E94: main (test_allocarg.f90:33)
==13675==
==13675== LEAK SUMMARY:
==13675== definitely lost: 1,760 bytes in 41 blocks
==13675== indirectly lost: 400 bytes in 20 blocks
==13675== possibly lost: 0 bytes in 0 blocks
==13675== still reachable: 0 bytes in 0 blocks
==13675== suppressed: 0 bytes in 0 blocks
==13675==
==13675== For counts of detected and suppressed errors, rerun with: -v
==13675== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 6)
Note in the test program the loop around the allocation subroutine call. Memory
leaks do NOT occur on the first call, only on subsequent calls when the array
is already allocated.
It appears the INTENT(OUT) attribute of the dummy argument with the allocatable
attribute is not being honoured.
cheers,
paulv
p.s. Below are the outputs of "gcc -v" on my linux box:
* For v4.8.2
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr1/wd20pd/local/gcc-4.8/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8-source/gcc-4.8-20130801/configure
--enable-languages=c,c++,fortran --enable-checking=release --disable-libmudflap
--disable-libstdcxx-pch --enable-libgomp --enable-lto --enable-gold
--with-plugin-ld=/usr/bin/gold --with-cloog-include=/usr/include-cloog
--with-cloog-lib=/usr/lib64 --prefix=/usr/local/gcc-4.8
Thread model: posix
gcc version 4.8.2 20130801 (prerelease) (GCC)
* For v4.9.2
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr1/wd20pd/local/gcc-4.9/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.9-source/gcc-4.9-20141001/configure
--enable-languages=c,c++,fortran --enable-checking=release --disable-libmudflap
--disable-libstdcxx-pch --enable-libgomp --enable-lto --enable-gold
--with-plugin-ld=gold --with-cloog-include=/usr/include-cloog
--with-cloog-lib=/usr/lib64 --prefix=/usr/local/gcc-4.9
Thread model: posix
gcc version 4.9.2 20141001 (prerelease) (GCC)
