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