[Bug libstdc++/54314] [4.8 Regression] undefined references to 'construction vtable for std::ostream-in-std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >'

["hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>]

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