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

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> Confirmed. Here is the most reduced test case I could construct from your
> original example:

-fdump-tree-original shows the following dump for this case:


polymorphic_operators_memory_leaks ()
{
  static struct a_type_t a = {.x=1.0e+0};
  static struct a_type_t b = {.x=2.0e+0};

  {
    struct __class_a_type_m_A_type_t_a D.3528;

    D.3528 = add_a_type (&a, &b);
    assign_a_type (&a, D.3528._data);
  }
}


As you can see we generate a temporary called 'D.3528' for the polymorphic
function result. All we have to do is to deallocate this temporary at the end.

When changing the function result from CLASS to TYPE, this deallocation seems
to be done properly (valgrind shows no leak), and the dump looks like this:

polymorphic_operators_memory_leaks ()
{
  static struct a_type_t a = {.x=1.0e+0};
  static struct a_type_t b = {.x=2.0e+0};

  {
    struct a_type_t * D.3511;
    struct a_type_t D.3512;

    D.3511 = add_a_type (&a, &b);
    D.3512 = *D.3511;
    __builtin_free ((void *) D.3511);
    D.3511 = 0B;
    assign_a_type (&a, &D.3512);
  }
}

Reply via email to