[Bug ipa/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)

hubicka at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Thu Oct 10 10:49:00 GMT 2013


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at redhat dot com

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Actually one thing I am puzzled about is the fact that ~B() that is being
devirtualized is COMDAT, but it reffers to the vtable that is external:

_ZTV1B/6 (int (* B::_ZTV1B [5])(...)) @0x7ffff7036a28
  Type: variable definition analyzed
  Visibility: external public virtual artificial
  Aux: @0x1  References: _ZTI1B/9 (addr)_ZN1BD1Ev/3 (addr)_ZN1BD0Ev/4
(addr)virtual int B::m_fn1()/10 (addr)
  Referring: _ZN1BD2Ev/2 (addr)
  Availability: not-ready
  Varpool flags: initialized read-only const-value-known
_ZN1BD0Ev/4 (virtual B::~B()) @0x7ffff70405f0
  Type: function definition analyzed
  Visibility: public weak comdat comdat_group:_ZN1BD0Ev one_only virtual
artificial
  Same comdat group as: _ZN1BD2Ev/2
  Address is taken.
  Aux: @0x1  References:
  Referring: _ZTV1B/6 (addr)
  Function flags: body
  Called by:
  Calls: void operator delete(void*)/5 (1.00 per call) _ZN1BD1Ev/3 (1.00 per
call) (can throw external)

Backend believe that every function with body defined can actually be inlined
(or there is no point to pass it down from FE at first place).
I wonder how C++ ends up with two different visibilities for these - B seems
keyed by the virtual function it defines, but why the destructor is not keyed
then as well?



More information about the Gcc-bugs mailing list