[Bug fortran/80477] [OOP] Polymorphic function result generates memory leak

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80477
--- Comment #18 from janus at gcc dot gnu.org ---
(In reply to paul.richard.tho...@gmail.com from comment #16)
> The attached does what you want to the testcase. For CLASS objects, it
> is the data that has to be copied to a variable, that data freed and
> the _data field pointed to the variable. There are about 70 failing
> tests.

I actually see 52 testsuite failures with your patch, namely in the files:

FAIL: gfortran.dg/alloc_comp_class_4.f03   -O0  execution test
FAIL: gfortran.dg/class_result_1.f03   -O1  (internal compiler error)
FAIL: gfortran.dg/class_to_type_4.f90   -O0  execution test
FAIL: gfortran.dg/init_flag_15.f03   -O0  execution test
FAIL: gfortran.dg/submodule_6.f08   -O0  execution test
FAIL: gfortran.dg/typebound_operator_8.f03   -O0  execution test


It seems the patch currently fails at runtime for cases where the class
variable has allocatable components, like this reduction of
alloc_comp_class_4.f03:


module test_pr58586_mod
  implicit none

  type :: c
     integer, allocatable :: a
  end type

contains

  subroutine add_class_c (d)
    class(c), value :: d
  end subroutine

  class(c) function c_init2()
    allocatable :: c_init2
  end function

end module test_pr58586_mod

program test_pr58586
  use test_pr58586_mod

  call add_class_c(c_init2())

end program


The dump is:


test_pr58586 ()
{
  {
    struct __class_test_pr58586_mod_C_a D.3598;
    struct c D.3599;

    D.3598 = c_init2 ();
    D.3599 = *D.3598._data;
    __builtin_free ((void *) D.3598._data);
    D.3598._data = 0B;
    D.3598._data = &D.3599;
    add_class_c (D.3598);
    if (D.3598._data != 0B)
      {
        if (D.3598._data->a != 0B)
          {
            __builtin_free ((void *) D.3598._data->a);
            D.3598._data->a = 0B;
          }
        __builtin_free ((void *) D.3598._data);
        D.3598._data = 0B;
      }
  }
}