http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60674
Bug ID: 60674
Summary: missed devirtualization in function called by
destructor
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: jason at gcc dot gnu.org
My recent patch for 60566 caused us to stop referring to destructors from
construction vtables; as a result, devirt-21.C and devirt-23.C started failing.
The fails aren't a new bug; we are no longer seeing the devirtualization
because we remove the path to wrap() through a virtual call to ~MultiTermDocs
that it occurred along. But it seems odd to me that it isn't happening on path
through a non-virtual call to ~MultiTermDocs. -fdump-ipa-cp before my patch
includes
Jump functions of caller virtual MultiTermDocs::~MultiTermDocs()/6:
callsite virtual MultiTermDocs::~MultiTermDocs()/6 -> void
MultiTermDocs::wrap()/3 :
param 0: KNOWN TYPE: base struct MultiTermDocs, offset 0, component
struct MultiTermDocs
Aggregate passed by reference:
offset: 0, cst: &MEM[(void *)&_ZTV13MultiTermDocs + 24B]
Jump functions of caller MultiTermDocs::~MultiTermDocs()/5:
callsite MultiTermDocs::~MultiTermDocs()/5 -> void MultiTermDocs::wrap()/3
:
param 0: PASS THROUGH: 0, op nop_expr
Why isn't the second callsite also considered KNOWN TYPE, since it's a call
from a 'structor? The gimple looks like
iftmp.6_4 = *__vtt_parm_3(D);
this_5(D)->_vptr.MultiTermDocs = iftmp.6_4;
MultiTermDocs::wrap (this_5(D));
so we know that the vtable pointer has just been updated. I've xfailed the
tests for now.
