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