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

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

Jason Merrill <jason at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #28065|0                           |1
        is obsolete|                            |
             Status|REOPENED                    |ASSIGNED
         AssignedTo|unassigned at gcc dot       |jason at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #20 from Jason Merrill <jason at gcc dot gnu.org> 2013-01-26 05:38:54 UTC ---
Created attachment 29277
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29277
proposed patch

This patch fixes the bug by setting DECL_VISIBILITY_SPECIFIED on the
constructor vtable.  Interestingly, can_refer_decl_in_current_unit_p only
checks for that in deciding whether or not it's safe to refer to an external
decl, not what the specified visibility is; as a result, this issue wasn't
showing up on linux-gnu because the standard library has an explicit
visibility("default").  On targets that don't use attribute visibility, this
was having trouble because the symbol had unspecified visibility at compile
time but then was made hidden by the linker script.  Is there something better
we can do about symbols that may or may not end up hidden at link time?

I think this change to make the constructor vtables hidden is safe because the
optimizer change that caused us to refer to them inappropriately is new in 4.8,
so we don't have to worry about ABI issues with earlier releases.

Any thoughts?