This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[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> >'
- From: "hubicka at ucw dot cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 28 Jan 2013 19:05:40 +0000
- Subject: [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> >'
- Auto-submitted: auto-generated
- References: <bug-54314-4@http.gcc.gnu.org/bugzilla/>
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