https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69080
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikael at gcc dot gnu.org
--- Comment #12 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to kargl from comment #11)
> (In reply to Mueller from comment #9)
> > (In reply to Mueller from comment #8)
> > > I think, in theory, the compiler could detect something like
> > >
> > > call some_subroutine(function_returning_allocatable())
> > >
> > > to be a potential case for automatic deallocation of the returned
> > > allocatable. But, as was pointed out above (if I understood correctly),
> > > automatic deallocation of allocatable function results is not part of the
> > > standard.
> >
> > Now that I'm thinking about the example above: Isn't the allocatable
> > function result here a local (temporary) variable and should thus be
> > deallocated automatically?
>
> No, it is not a local temporary variable. If the function
> result is deallocated prior to returning from the function,
> what exactly is going to be returned? Whatever had been stored
> in the memory associated with the allocated function result
> variable would be gone. That is, you can't reference
> unallocated memory.
>
I think by local temporary he was meaning local to the _outer_ procedure call,
not local to the inner procedure body.
For the following code
call foo(some_func())
a temporary variable is made to hold the value of some_func() before calling
foo, and it is cleaned up after foo has returned.
I think the point is not whether the return value should be deallocated before
returning (it should not as stated by Steve), it is instead whether it should
be deallocated after being used as actual argument (in my opinion it makes
sense to do it).
