This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/80726] [7/8 Regression] Destructor not inlined anymore (regression)


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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Strange, I see it not inlined with -O3 only starting with r254724 on
x86_64-linux.

I bet it is related to:
  if (cur_node->same_comdat_group)
    {
      /* TODO: call is versionable if we make sure that all
         callers are inside of a comdat group.  */
      cur_node->calls_comdat_local = 1;
      node->add_to_same_comdat_group (cur_node);
    }

I think not inlining the whole destructor is desirable, the throw stuff is
unnecessarily large and cold.  What I don't understand is why we'd want to emit
the _ZN3FooD2Ev.part.0 function inside of any comdat section, that is obviously
something we can't do (e.g. because not all TUs that emit the destructor would
emit _ZN3FooD2Ev.part.0 too or some could emit .part.24 etc.) and that is why
inlining fails.  Can't we just emit a static _ZN3FooD2Ev.part.0 function in the
text section instead?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]