From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19699 invoked by alias); 5 Feb 2007 19:52:28 -0000 Received: (qmail 19629 invoked by uid 48); 5 Feb 2007 19:52:15 -0000 Date: Mon, 05 Feb 2007 19:52:00 -0000 Message-ID: <20070205195215.19628.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/29487] Shared libstdc++ fails to link In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "amylaar at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-02/txt/msg00727.txt.bz2 ------- Comment #27 from amylaar at gcc dot gnu dot org 2007-02-05 19:52 ------- (In reply to comment #25) > I think the analysis should be deeper than just "binds_local_p", though; > I think it should be based on whether "attribute ((weak))" (or > equivalent) explicitly appears, so that we don't pessimize bar if foo is > in a template function, out-of-line inline, or other such function. The > test ought to be based on the demonstrable intent of the user to replace > the function, not on whether or not the function happens to be weak. What about an exported definition in a shared library? Users expect to be able to replace such definitions. Should we constrain them in what they can replace these definitions with by requiring them not to extend the throw specification beyond what gcc could figure out about it using data and control flow analysis on the original definition? That defeats the purpose of defining an interface with prototypes. > > I agree. If my suggestion above seems correct, then the first step is > to undo the change that make "foo" not marked TREE_NOTHROW. Sorry, but at the moment we have no way of making "foo" marked TREE_NOTHROW. We can only mark its declaration TREE_NOTHROW, which then causes all the callers to assume that the function of that name doesn't throw. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487