[Bug tree-optimization/62091] [5 Regression] ice in before_dom_children

hubicka at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Thu Aug 14 18:51:00 GMT 2014


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

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
I added the comment to wrong PR so I am moving it here:

Hi,
There are two issues seen with the testcase.  First is that ipa-devirt misses
the ctor call that can be easily fixed by:
Index: ipa-devirt.c
===================================================================
--- ipa-devirt.c        (revision 213969)
+++ ipa-devirt.c        (working copy)
@@ -2663,6 +2663,8 @@
                          * BITS_PER_UNIT;
                op = TREE_OPERAND (op, 0);
              }
+           else if (DECL_P (op))
+             ;
            else
              {
                 tci->speculative = true;

I am testing this patch.

However even with this change we won't devirtualize because we believe that we
can not reffer to the virtual method.
The node is:
(gdb) p snode->dump (stderr)
_ZNK1A5m_fn1Ev/3 (virtual SnmpSyntax* A::m_fn1() const) @0x7ffff6dad8a0
  Type: function definition analyzed
  Visibility: external public weak comdat comdat_group:_ZNK1A5m_fn1Ev one_only
virtual
  Address is taken.
  References: 
  Referring: _ZTV1A/12 (addr)
  Availability: available
  First run: 0
  Function flags: body
  Called by: 
  Calls: 

I wonder what we should do with both external and comdat here.  Jason, can we
devirtualize?
The constructor is keyed to other compilation unit here, but we are provided
with a body
that we will never use (modulo the tree-ssa-pre bug that brings the reference
into code).

I can imagine implementing logic to make us to devirtualize only when inlining
and never introduce
direct refernece otherwise, but it would be quite work - so far we always need
the intermediate
reference before inlining. (Basically we will need to make ipa-devirt to
produce direct call and
revert if inliner fails to inline the function at the end of IPA queue).



More information about the Gcc-bugs mailing list