From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8883 invoked by alias); 5 Feb 2007 19:33:22 -0000 Received: (qmail 8798 invoked by alias); 5 Feb 2007 19:33:07 -0000 Date: Mon, 05 Feb 2007 19:33:00 -0000 Message-ID: <20070205193307.8797.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/msg00720.txt.bz2 ------- Comment #25 from mark at codesourcery dot com 2007-02-05 19:33 ------- Subject: Re: Shared libstdc++ fails to link rguenth at gcc dot gnu dot org wrote: [Paolo, see below for question.] > ------- Comment #20 from rguenth at gcc dot gnu dot org 2007-02-05 09:06 ------- > What we want to prevent with the patch for PR29323 is the TREE_NOTHROW flag > propagating to a locally binding function. Consider > > void foo() nothrow __attribute__((weak)) {} > > void bar() > { > foo(); > } > > we need EH unwind data emitted for bar() even if foo() is marked or > analyzed as nothrow as at run time bar() might call a foo() that throws. > > At least if using C and -fexceptions this is a valid use (we of course > can declare this invalid for C++, but this can be a runtime error only > which will then be hard to diagnose). I think I agree that the C -fexceptions example is compelling, and I find the same example in C++ reasonably compelling too, the ODR notwithstanding, since that's clearly the intent of __attribute__((weak)). > I'm in no way expert enough to say if we can omit EH data for foo() in > the above case (we probably can), but if so then splitting the TREE_NOTHROW > flag into two is probably the right thing to go. I don't think there's any reason we should need EH data for foo. I would think that it is in fact reasonable to mark "foo" TREE_NOTHROW. However, when analyzing bar() (which we do by walking its body, looking for calls, to work out whether anything that bar calls can throw an exception), we should avoid marking "bar" TREE_NOTHROW in this case. 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. > I suppose PR29323 was found by inspection of GCC code rather than a real-world > testcase so the option to revert that patch on the 4.1 branch looks appealing. I agree. If my suggestion above seems correct, then the first step is to undo the change that make "foo" not marked TREE_NOTHROW. Since that restores the 4.1.1 status quo, will presumably fix HP-UX 10.10, and eliminate any pessimization in 4.1.2, I think we should do that. The same reversion should be applied to mainline and 4.2, since the same considerations apply there. If we get excited about fixing the pre-existing problem with weak functions, we can do that later. Paolo, would you be able to undo the change to make "foo" not marked TREE_NOTHROW? IIUC, that would be different than the patch you posted in Comment #22, which appears to affect "bar". Also, I didn't quite understand your patch, in that it would appear to result in fewer functions being marked TREE_NOTHROW, whereas we want more functions to be so marked to restore status quo? I would think we want to remove the check for binds_local_p at the top of set_nothrow_function_flags? Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487