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?
