[Bug ipa/62051] [4.9/5/6 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively

hubicka at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Thu Feb 11 03:59:00 GMT 2016


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

--- Comment #15 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> > The patch simply prohibits references to all COMDAT and EXTERN methods and
> > vtables of types with visibility attributes which will prevent optimizing of
> > many inlines i.e. in libstdc++.
> 
> Hmm?  This shouldn't affect libstdc++ at all; it doesn't set visibility on 
> individual member functions, only on whole namespaces.  This should only affect > code that plays these kinds of partial export games.

I see, I sort of remembered that libstdc++ does that but I was wrong. If you
think it is not problem to disable most of devirtualization on these, I am fine
with the patch and will commit it ASAP (I am on trip to China till 22nd, but
seems I finally got to place with useable internet connection).

> > It still seem to me that the the testcase is sort of invalid because it
> > provide inline body for the dtor.
> 
> Agreed, but if it were out-of-line we'd have the same problem with devirt trying to call the dtor directly.

Well, if it were out of line, we would have external symbol and
can_refer_in_this_unit_p is already quite careful about these.

So far we make an assumption that whenever we have COMDAT inline or extern
inline, we always can inline it (or, more or less equivalntly, introduce
references to the comdat). Only exception here is speculative devirtualization
to artificial bodies you added. We still fully devirtualize or constant fold to
those.

Having "do not touch" function bodies in the callgraph seems bit odd.
I assume it is still useful for C++ FE to handle those untouchable function
bodies to us as we could do IPA analysis and work out the side effects. We
won't do that as IPA propagation passes (ipa-const/ipa-reference/ipa-cp) does
not really consider may edges yet. I plan to add that next stage1.


More information about the Gcc-bugs mailing list