https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81702
Martin Jambor <jamborm at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hubicka at gcc dot gnu.org
--- Comment #3 from Martin Jambor <jamborm at gcc dot gnu.org> ---
This is a devirtualization issue and I tend to think that the correct
fix is to remove the assert. But I'd like to know what Honza thinks
about it. The situation is as follows:
Looking into release_ssa dump, we see a static initializer calling a
constructor:
Type_matcher<Fa<Res, Res>, Res*>::Type_matcher (&MEM[(struct Fa*)&_x].D.2542,
&_ZTI3Foo);
Note the second parameter, which is a result of typeid C++ operator
(line 97 of the testcase). My patch with which this starts to ICE is
able to extract aggregate values from its constructor, which comes
down to:
{ &MEM[(void *)&_ZTVN10__cxxabiv117__class_type_infoE + 16B], &_ZTS3Foo }
No field_decl in the constructor is called _vptr, by the way.
The Type_matcher constructor then calls virtual method __do_catch of
that second parameter (called t), which in turn results into the
following gimple sequence:
...
_1 = t_8(D)->_vptr.type_info;
_2 = *_1;
...
OBJ_TYPE_REF(_2;(const struct type_info)t_8(D)->0) (t_8(D), _3, 0B, 0);
ipa_find_agg_cst_for_param now figures out that at offset zero of t
there is &MEM[(void *)&_ZTVN10__cxxabiv117__class_type_infoE + 16B]
and vtable_pointer_value_to_vtable then identifies
_ZTVN10__cxxabiv117__class_type_infoE as the virtual table.
But that thing has NULL DECL_INITIAL, which we only expect in LTO and
so ICE. I do not quite understand how it is supposed to be
initialized, there is no construction of it in the dump either. But
then I do not really know how C++ RTTI works...
But that is the fundamental question. If we cannot get at the values
of that virtual table, we can only remove the assert, inf not, we can
try to extract them somehow. Honza?
