[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> >'

["jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54314

--- Comment #24 from Jason Merrill <jason at gcc dot gnu.org> 2013-01-27 01:44:49 UTC ---
(In reply to comment #21)
> I must say I'm surprised by the gimple-fold.c test, I'd really expect
> additional && DECL_VISIBILITY (decl) != VISIBILITY_DEFAULT .

I'd actually expect DECL_VISIBILITY (decl) < VISIBILITY_PROTECTED, and not
check DECL_VISIBILITY_SPECIFIED at all.  I don't think it matters whether the
visibility that the decl ends up with is specified or inferred.

> Another alternative to make those always hidden (which could be an exported
> ABI change for some shared libraries, though unlikely to be actually a real
> problem)

At worst, it removes some unnecessarily exported symbols.  Which might cause
ABI checkers to complain, but nothing else should refer to them; if something
else had, we would have seen this bug before.  I think marking them as hidden
is desirable, as it avoids unnecessary exports for user libraries that don't
use linker scripts or explicit visibility as well as fixing this bug.

(In reply to comment #23)
> It seems C++ frontend has to mark those
> declarations as unusable for referencing.  Is it easy to do on C++ side?
> I think we want tree visibility flag here, because we do not really represent
> stuff that may get into the game with TBAA.

I don't understand.  My patch sets DECL_VISIBILITY to hidden; are you talking
about a different tree visibility flag?