[Bug target/29487] Shared libstdc++ fails to link

[mark at codesourcery dot com]

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