[Bug fortran/51160] [OOP] Memory leak with abstract type

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51160

janus at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |4.9.0

[Bug fortran/51160] [OOP] Memory leak with abstract type

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to Tobias Burnus from comment #1)
 I think your issue has nothing to do with abstract types but rather with
 working with polymorphic data (CLASS).
 
 I think the issue is that r's u component in sub is not freed at the
 end, which would be a duplicate of PR 46321.

Correct. And now that polymorphic deallocation is implemented, also the memory
leak is gone: The dump shows that the _final procedure is called, and also
valgrind reports a clean memory footprint:

==5457== HEAP SUMMARY:
==5457== in use at exit: 0 bytes in 0 blocks
==5457==   total heap usage: 423 allocs, 423 frees, 58,341 bytes allocated
==5457== 
==5457== All heap blocks were freed -- no leaks are possible

[Bug fortran/51160] [OOP] Memory leak with abstract type

[burnus at gcc dot gnu.org]

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

Tobias Burnus burnus at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||wrong-code
 CC||burnus at gcc dot gnu.org,
   ||janus at gcc dot gnu.org
Summary|Memory leak with abstract   |[OOP] Memory leak with
   |type|abstract type

--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-11-16 
15:41:41 UTC ---
I think your issue has nothing to do with abstract types but rather with
working with polymorphic data (CLASS).

I think the issue is that r's u component in sub is not freed at the end,
which would be a duplicate of PR 46321.