From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 874 invoked by alias); 5 Feb 2007 20:08:47 -0000 Received: (qmail 492 invoked by alias); 5 Feb 2007 20:08:28 -0000 Date: Mon, 05 Feb 2007 20:08:00 -0000 Message-ID: <20070205200828.490.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: "mark at codesourcery dot com" 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/msg00728.txt.bz2 ------- Comment #28 from mark at codesourcery dot com 2007-02-05 20:08 ------- Subject: Re: Shared libstdc++ fails to link amylaar at gcc dot gnu dot org wrote: > ------- 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? Yes, I believe that we should forbid this kind of replacement. We can, if necessary, make GCC not be more conservative than the original exception-specification if present, so that: void foo() throw (X) {} still results in the compiler thinking that "foo" may throw "X", but we should not extent that to thinking that: void foo() {} can throw anything. That's making the compiler generate inferior code, for a corner-case situation, outside the realm of the language. Making the user use an attribute to declare what they mean is not unreasonable. > 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. Yes, which was the status quo before your patch. I don't see any good argument for exchanging the relatively obscure problem fixed by the patch for a different set of problems: broken HP-UX 10.10, and inferior code for C++ applications that are not using either weak functions or shared libraries. Therefore, I think we should go back to marking "foo" TREE_NOTHROW, and look for a more a complete fix to both your original problem and the other cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487