https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2017-04-22
CC| |janus at gcc dot gnu.org
Target Milestone|--- |8.0
Summary|Polymorphic functions (thus |[OOP] Polymorphic function
|operators) generates memory |result generates memory
|leaks |leak
Ever confirmed|0 |1
--- Comment #3 from janus at gcc dot gnu.org ---
Confirmed. Here is the most reduced test case I could construct from your
original example:
module a_type_m
implicit none
type :: a_type_t
real :: x
endtype
contains
subroutine assign_a_type(lhs, rhs)
type(a_type_t), intent(inout) :: lhs
type(a_type_t), intent(in) :: rhs
lhs%x = rhs%x
end subroutine
function add_a_type(lhs, rhs) result( res )
type(a_type_t), intent(in) :: lhs
type(a_type_t), intent(in) :: rhs
class(a_type_t), allocatable :: res
allocate (a_type_t :: res)
res%x = lhs%x + rhs%x
end function
end module
program polymorphic_operators_memory_leaks
use a_type_m
implicit none
type(a_type_t) :: a = a_type_t(1) , b = a_type_t(2)
call assign_a_type (a, add_a_type(a,b)) ! generates memory leak
end
valgrind shows the following output for all gfortran versions I tried (from 4.7
to trunk):
==6131== HEAP SUMMARY:
==6131== in use at exit: 4 bytes in 1 blocks
==6131== total heap usage: 20 allocs, 19 frees, 12,012 bytes allocated
==6131==
==6131== LEAK SUMMARY:
==6131== definitely lost: 4 bytes in 1 blocks
==6131== indirectly lost: 0 bytes in 0 blocks
I think it's indeed a duplicate of PR 60913.
