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

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