https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477
Paul Thomas <pault at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #27 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to zed.three from comment #26)
> Thank you for looking at the finalisation stuff, Paul, it's really
> appreciated!
>
> It wasn't clear to me from the patch notes if you expect the following to be
> fixed:
>
> subroutine assign_a_type(lhs, rhs)
> class(a_type_t), intent(inout) :: lhs
> class(a_type_t), intent(in) :: rhs
> lhs%x = rhs%x
> end subroutine assign_a_type
>
> or
>
> class(a_type_t), allocatable :: c
> c = add_a_type(a, b)
>
> These still generate memory leaks (detected using -fsanitize=address)
>
> I'm using trunk (r267184, git bf96f3)
>
> I've been trying to dig into the code myself, mostly as a learning exercise.
> Am I right in thinking that gfc_conv_procedure_call handles the whole
> statement? i.e. that finalisation both of the lhs and function result are
> (or should be) done here?
I am unable to reproduce the memory leaks that you mention, either with
-fsanitize=address or valgrind.
The statement is handled by gfc_conv_procedure_call as you say.
I am closing this PR since it is fixed on trunk.
Paul
