http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314
--- Comment #28 from Jan Hubicka <hubicka at ucw dot cz> 2013-01-28 19:05:40 UTC --- > > 1) Just add the check. We will then miss all devirtualization oppurtunities > > through the construction vtable. > > The front end does devirtualization itself for calls within constructors, so > the impact of this isn't likely to be too bad. Does it cover all the cases we can potentially handle by middle-end? Or does it stop i.e. at function boundary? On the other hand I would say that calls close to consturction are those that are likely to be devirtualized, so we should not ignore thoe. > > what happens on targets not supporting visibility? > > I think that setting DECL_VISIBILITY should do the trick even if it isn't > reflected in the assembly output. I added the DECL_ARTIFICIAL check to > default_assemble_visibility so that this wouldn't cause warnings. Yes, that seem like way to go. > > > 3) Perhaps we can use DECL_VALUE_EXPR or somethin similar to keep track of > > the canonical way to reffer into tthe construction vtable? (i.e. by > > reference > > to vtable) We can then lower all direct references to the indirect > > references late, i.e. in expansion? > > Hmm, that makes sense. OK, if you help me with C++ bits, I can give this a try. Honza
