https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
CC| |kargl at gcc dot gnu.org
Resolution|--- |INVALID
--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to sv.mueller from comment #3)
> Thanks for testing this out!
>
> Indeed there aren't any leaks with your changes. Actually, leaving the
> module save statement uncommented produces the same positive result for me.
>
> However, I don't think this is a solution. If you, for example, think of a
> string class as the derived type instead of "dummy", there could be a
> function returning an allocatable string_class derived type. This string
> function result could be used somewhere in a subroutine as input, but the
> subroutine doesn't know if the string will still be used outside of the
> subroutine. So there is no way the subroutine should deallocate the string.
>
> I know that allocatables that are declared in the program itself aren't
> deallocated automatically because of the implicit save attribute. But my
> thinking was that Fortran will take care of deallocating allocatables in all
> other cases. Of course, I may be mistaken.
When the execution of a procedure is terminated by execution of a
RETURN or END statement, an allocatable variable that is a named
local variable of the procedure retains its allocation and definition
status if it has the SAVE attribute or is a function result variable
or a subobject thereof; otherwise, it is deallocated.
