428306 - Unexpected dtor types calling `operator delete`

Status: RESOLVED INVALID

(Developer Infrastructure :: Source Code Analysis, defect)

Description

[Benjamin Smedberg]

I am starting to use the finalizer-safety script from bug 424416.

I have strange results for virtual destructors: the three types of destructor all seem to be calling `operator delete`. I made a small testcase available here: http://hg.mozilla.org/users/bsmedberg_mozilla.com/testcases/index.cgi/file/1f17fee3a3fa/treehydra/

The results are:
"A::__deleting_dtor "   "operator delete
"A::__comp_dtor "       "operator delete
"A::__base_dtor "       "operator delete

I would expect that only the __deleting_dtor would call operator delete. The other two should not.

Is this an error in the treehydra script? Or am I confused about the different variety of constructors?

Comment 1

[David Mandelin [:dmandelin]]

I think you are correct and everything is working correctly, which is of course very confusing. :-)

I took a quick look at the output of 'g++ -fdump-tree-cfg -c destructor-calls.cpp', and I saw that there are in fact 3 destructor functions, and all of them contain an invocation of operator delete. But the code looks like this:

  tmp = 1;   // one function has '1', the others have '0' here
  tmp2 = (bool) tmp;
  if (tmp2)
    delete this;
  return;

For some reason, this dump doesn't give the readable names that you script does, but I think it's safe to guess that '__deleting_dtor' is the one with a 1.

Comment 2

[Benjamin Smedberg]

Yikes, ok. Thanks for the explanation.

Comment 3

[Zack Weinberg (:zwol)]

As an old GCC head, perhaps I can shed some light on why the code generation here is so weird ... The routine in the C++ front end that synthesizes this code sequence was originally used to emit constructor calls for function-scope objects with static storage duration, where the code goes like so:

  static T thing;  // zero-initialized in object file
  static int thing_guard;  // invisible variable

  if (thing_guard == 0)
    {
      T::T(); // with this-parameter == thing
      thing_guard = 1;
    }

Over time the code template got more general as it grew support for thread-safe initialization, shared library unloading, &c. &c. &c.  And at some point someone repurposed it to also deal with destructor bodies.

I think, also, that you are dumping out the tree structure in the middle of the optimization sequence; compare what you get with -fdump-tree-original and -fdump-tree-optimized.  And, of course, the ultimate assembly output; there's another couple dozen low-level "RTL" optimizers after the point where -fdump-tree-optimized happens (you can dump their IL too but it's a lot harder to read).  At -O2, all this junk *should* have gone away in tree optimization, and it's definitely a GCC bug if it hasn't gone away in the .s file.