[Bug fortran/63473] New: Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.

[Bug fortran/63473] New: Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.

[paul.vandelst at noaa dot gov]

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)

[Bug fortran/63473] [4.9/5 Regression] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-12-16
                 CC|                            |janus at gcc dot gnu.org
            Version|4.8.2                       |4.9.1
            Summary|Memory leak with            |[4.9/5 Regression] Memory
                   |ALLOCATABLE, INTENT(OUT)    |leak with ALLOCATABLE,
                   |dummy arguments.            |INTENT(OUT) dummy
                   |                            |arguments.
     Ever confirmed|0                           |1

--- Comment #2 from janus at gcc dot gnu.org ---
Confirmed.

> ==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)

This one I see with all gfortran versions I tried (4.4.7, 4.6.4, 4.7.4, 4.8.3,
4.9.1, trunk).


> ==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)

This one only seems to occur with 4.9 and trunk, i.e. it's a regression.

[Bug fortran/63473] [4.9/5 Regression] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473

--- Comment #3 from janus at gcc dot gnu.org ---
Here is a slightly compactified test case:


program testprogram
  implicit none
  type :: mytype_type
    integer, allocatable :: i(:)
  end type
  integer :: n
  type(mytype_type), allocatable :: array(:)

  do n = 1, 2
    print *, allocated(array)
    call allocate_mytype(array)
  end do

contains

  subroutine allocate_mytype(array)
    type(mytype_type), allocatable, intent(out) :: array(:)
    integer :: i
    allocate(array(10))
    do i = 1, 10
      allocate(array(i)%i(5))
      array(i)%i = 0
    end do
  end subroutine

end


With 4.9.1, valgrind shows:


==31043== HEAP SUMMARY:
==31043==     in use at exit: 880 bytes in 21 blocks
==31043==   total heap usage: 43 allocs, 22 frees, 13,201 bytes allocated
==31043== 
==31043== 200 bytes in 10 blocks are definitely lost in loss record 2 of 3
==31043==    at 0x4C2ABA0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31043==    by 0x400BC6: allocate_mytype.2336 (test.f90:21)
==31043==    by 0x400EF3: MAIN__ (test.f90:11)
==31043==    by 0x400F40: main (test.f90:9)
==31043== 
==31043== 680 (480 direct, 200 indirect) bytes in 1 blocks are definitely lost
in loss record 3 of 3
==31043==    at 0x4C2ABA0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31043==    by 0x4009A1: allocate_mytype.2336 (test.f90:19)
==31043==    by 0x400EF3: MAIN__ (test.f90:11)
==31043==    by 0x400F40: main (test.f90:9)
==31043== 
==31043== LEAK SUMMARY:
==31043==    definitely lost: 680 bytes in 11 blocks
==31043==    indirectly lost: 200 bytes in 10 blocks
==31043==      possibly lost: 0 bytes in 0 blocks
==31043==    still reachable: 0 bytes in 0 blocks
==31043==         suppressed: 0 bytes in 0 blocks


The first message (200 bytes) occurs with all gfortran versions I tried (and
only in the second loop execution).

The second message (680 bytes) occurs only with 4.9 upwards (and already in the
first loop execution).

[Bug fortran/63473] [4.9/5 Regression] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> The second message (680 bytes) occurs only with 4.9 upwards (and already in
> the first loop execution).

Actually I think this is not a real regression, but rather a change in behavior
which is in line with the Fortran 2008 standard (variables in the main program
automatically get the SAVE attribute, and thus are not auto-deallocated).

One can get rid of that valgrind message, by explicitly deallocating the array
at the end of the main program, so that the test case becomes:


program testprogram
  implicit none
  type :: mytype_type
    integer, allocatable :: i(:)
  end type
  integer :: n
  type(mytype_type), allocatable :: array(:)

  do n = 1, 2
    print *, allocated(array)
    call allocate_mytype(array)
  end do

  deallocate(array)

contains

  subroutine allocate_mytype(array)
    type(mytype_type), allocatable, intent(out) :: array(:)
    integer :: i
    allocate(array(10))
    do i = 1, 10
      allocate(array(i)%i(5))
      array(i)%i = 0
    end do
  end subroutine

end


With this version, one only gets:

==31267== 200 bytes in 10 blocks are definitely lost in loss record 1 of 1
==31267==    at 0x4C2ABA0: malloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31267==    by 0x400BC6: allocate_mytype.2336 (test.f90:23)
==31267==    by 0x400EF6: MAIN__ (test.f90:11)
==31267==    by 0x401008: main (test.f90:14)

[Bug fortran/63473] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.9/5 Regression] Memory   |Memory leak with
                   |leak with ALLOCATABLE,      |ALLOCATABLE, INTENT(OUT)
                   |INTENT(OUT) dummy           |dummy arguments.
                   |arguments.                  |

--- Comment #5 from janus at gcc dot gnu.org ---
-fdump-tree-original shows the following:


            if (array.data != 0B)
              {
                __builtin_free ((void *) array.data);
              }
            array.data = 0B;
            allocate_mytype (&array);


So: Before the call to 'allocate_mytype', the array itself is being
auto-deallocated, but its components are not!

[Bug fortran/63473] Memory leak with ALLOCATABLE, INTENT(OUT) dummy arguments.

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63473

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #6 from Mikael Morin <mikael at gcc dot gnu.org> ---
Seems to work now.  FIXED?