This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ia64 unwind thoughts
>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:
> On Fri, Feb 23, 2001 at 10:52:13AM +0000, Jason Merrill wrote:
>> I believe that the intent is that a pure cleanup will have no action
>> record, just a landing pad.
> How? "A missing entry in the call-site table indicates that a call
> is not supposed to throw." Now consider
> f1 ();
> try {
> f2 ();
> } catch (...) {
> }
> Clearly f1 must have a call-site entry, because it may throw.
Yes.
> But there are no cleanups to perform, so surely this is what "no action"
> is intended to represent?
If there are no cleanups, we should give a null landing pad offset as well,
since we don't need to return to the function.
The entry for the call to f2 would have a landing pad and an action record
with a type index of 0.
> I wonder about the wisdom of the missing entry decision. In HP's
> own document they mention that inlining a destructor can screw up
> the destructor in cleanup not allowed to throw detection. Seems
> like a better choice would have been an action record with an
> exception specification with an empty list of types.
Except that would produce a call to unexpected(), which isn't right either.
It seems to me that we could handle the problem you mention by setting
TREE_NOTHROW on any calls in the inlined copy of the destructor which
aren't in a try block, so they don't get call site info either.
This is a useful optimization; the exception regions for calling
terminate() if a cleanup throws are a significant chunk of our EH
overhead.
Another option, as you suggest, would be to treat calls with no entry as
requiring no cleanup, and continuing to unwind. Then we would need another
representation for calls not allowed to throw, and we would need to apply
*that* recursively. The problem with this is TREE_NOTHROW calls; IMO we
definitely want to omit call site info for them, and I think it makes more
sense to treat calls which are not expected to throw the same as calls
which are not allowed to throw.
On the other hand, leaving out the info for calls that just unwind is more
similar to the case of a function with no cleanups, where we can leave out
the LSDA entirely...
BTW, weren't you planning to stick with PC ranges rather than specific call
sites, anyway?
>> The cleanups don't became handlers; call sites within the inlined function
>> gain action records that refer to the handlers for the enclosing try
>> blocks.
> If there are no enclosing try blocks? Say if f1 got inlined
> in the above example?
Then they still have no action records.
Jason