[Bug c++/80763] [7/8 Regression] -O3 causes error: inline clone in same comdat group list

marxin at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Mon Aug 14 08:31:00 GMT 2017


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

Martin Liška <marxin at gcc dot gnu.org> changed:

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

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
Created attachment 41987
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41987&action=edit
Patch candidate

I wrongly pasted 2 patches to a different PR.

Adding patch candidate that changes cgraph_node::verify_node that verifies
global.inlined_to && same_comdat_group. It believe proper fix is to verify that
node should live in a same comdat group (if belongs to any).

Honza's reply:

OK, so now the tests passes when inline clone is either in no comdat group list
(even if function inlined to is in one) or if the comdat groups are the same. 
Does it fail when we test that comdats groups are always the same?  It seems
iffy to allow silently both.  I guess both variants are fine, but lets pick one
of them. Perhaps we want only to remove node from comdat group list while
inlining it.

My reply:
I'm going to test it whether more strict test will survive.
Honza

--- Comment #9 from Martin Liška <marxin at gcc dot gnu.org> ---

So having:

  if (global.inlined_to
      && get_comdat_group () != global.inlined_to->get_comdat_group ())
    {
      error ("inline clone in a different comdat group list");
      error_found = true;
    }

fails in situation like this:

namespace {
class a
{
public:
  a ();
};
class b : a
{
};
}
namespace c {
class e : b
{
};
d () { e (); }
}

ice.i:12:7: error: inline clone in a different comdat group list
 class e : b
       ^
_ZN12_GLOBAL__N_11bC2Ev/1 ({anonymous}::b::b()) @0x2b14a0ce4170
  Type: function definition analyzed
  Visibility: prevailing_def_ironly artificial
  References: 
  Referring: 
  Function {anonymous}::b::b()/1 is inline copy in c::e::e()/4
  Availability: local
  First run: 0
  Function flags: body local
  Called by: c::e::e()/4 (inlined) (1.00 per call) (can throw external) 
  Calls: {anonymous}::a::a()/7 (1.00 per call) (can throw external) 
during GIMPLE pass: einline
ice.i:12:7: internal compiler error: verify_cgraph_node failed
0x979eb3 cgraph_node::verify_node()
        ../../gcc/cgraph.c:3537
0x96e15c symtab_node::verify()
        ../../gcc/symtab.c:1204
0xe241b9 expand_call_inline
        ../../gcc/tree-inline.c:4581
0xe27184 gimple_expand_calls_inline
        ../../gcc/tree-inline.c:4954
0xe27184 optimize_inline_calls(tree_node*)
        ../../gcc/tree-inline.c:5094
0x1556a39 early_inliner(function*)
        ../../gcc/ipa-inline.c:2727

So do you prefer changing the comdat group when inlining or original version of
verifier is preferred?

Honza:


I would say that we have loops walking all symbols in given comdat group that
are not
really expecting to trip over inline clones, so it may be easier to
consistently take
inline clones out of the comdat group rather than consistently to put them in.

Honza


More information about the Gcc-bugs mailing list