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

["dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca  2007-02-05 04:02 -------
Subject: Re:  Shared libstdc++ fails to link

> I'm not sure it matters, but if these functions don't throw exceptions,
> I don't understand why we're not marking them TREE_NOTHROW.  I suspect
> there's something that I'm just not following.

See the testcase for PR 29323 and the initial problem description.

> The fact that linker semantics allow you to replace a function at the
> object level do not make it valid at the language level.
> 
> So, for example, I would expect:
> 
>   void f () throw () {}

This is essentially identical to the example in weakthrow.C except
that the function there is annotated with __attribute__ ((weak)).

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.  However, as far
as unwind data goes, the only thing that matters is whether the
function being compiled needs unwind data or not.

> Why aren't the functions being marked TREE_NOTHROW?

When a function doesn't bind locally, it may be overloaded/replaced
by one that does throw.  So, we no longer mark such functions with
TREE_NOTHROW.  This results in unwind data being emitted for functions
that would have been marked TREE_NOTHROW if they were local.

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

Yes, config.gcc could be modified to force SJLJ exception handling.
Of course, I'm hoping for a better fix to PR 29323.

Dave


-- 


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