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)
