From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-413353-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 16354 invoked by alias); 27 Jan 2013 01:45:25 -0000
Received: (qmail 14392 invoked by uid 48); 27 Jan 2013 01:44:52 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
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> >'
Date: Sun, 27 Jan 2013 01:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Keywords: link-failure
X-Bugzilla-Severity: major
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.0
X-Bugzilla-Changed-Fields:
Message-ID: <bug-54314-4-TGhJR2mpIH@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-54314-4@http.gcc.gnu.org/bugzilla/>
References: <bug-54314-4@http.gcc.gnu.org/bugzilla/>
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2013-01/txt/msg02472.txt.bz2


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?