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

["amylaar at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #24 from amylaar at gcc dot gnu dot org  2007-02-05 19:26 -------
(In reply to comment #18)
> It was argued in PR 29323 that it was incorrect to mark functions
> that don't bind locally with TREE_NOTHROW.
> 
> I'm not sure whether it's valid at the language level to replace
> a function that can't throw with one that can.

Remember that the determination if the function can throw or not is made by
analyzing the rtl of the function.  I.e. there might have been a throw
statement in the source, which was optimized away, so that the compiler
can then determine that the function does not actually throw.
Thus, TREE_NOTHROW can depend on how good the compiler is at solving specific
instances of the halting problem.  These might involve mathematical theorems
that are yet unproven, but might be in the future so that a funture compiler
can make use of it.
Thus, if you require that a function that can't throw can't be replaced by one
that can, you won't be able to decide if the program is valid till the
mathematical theorem is either proven or disproven.

Moreover, if, as the languguage level, you consider the C or C++ standard, we
can't actually replace functions in first place.
If that is what you want, you can use the appropriate visibility attribute
in the delacation, and save a lot of overhead for each function call.
If you want the function to be replacable, but don;t want the overhead of it
being consider potentially throwing, you can again express this with the
appropriate attribute in the declaration.

> 
> > Assuming that the changes in TREE_NOTHROW and emission of exception
> > information make sense, what solution would you implement for HP-UX 10?

If the affected library functions in fact are not supposed to be replaced by
functions that can throw, adding declarations with nothrow attribute will
get you the performance back for the callers.
It would also solve the immediate problem of the excess EH information for
the function definitions, although I agree that we generally shouldn't emit
it when we can reasonably determine that the actual function definition
doesn't throw, even when the declaration says that it may.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29487