[Bug fortran/58229] [F03] Memory leak with allocatable function result

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58229

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
 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 probably needs to happen inside gfc_conv_procedure_call (trans-expr.c).

[Bug fortran/58229] [F03] Memory leak with allocatable function result

[janus at gcc dot gnu.org]

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