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

["janus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot 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).