Re: ia64 c++ abi exception handling

[Richard Henderson <rth at redhat dot com>]

On Mon, Mar 12, 2001 at 05:10:58PM +0000, Jason Merrill wrote:
> Keep things as they were for now, I think.  The expansion needs to happen
> before inlining, which happens before we start generating RTL.

Done.

> I don't agree with the name change; the original idea was to support
> unwinding at any point at all, including out of a signal handler triggered
> by an external signal, an asynchronous event.  This doesn't actually work,
> though.

Right, and people try to use it for that all the time, so
I wanted to change it to something else.

> If you want to change the name, I'd prefer something clearer,
> like 'flag_non_call_exceptions'.

That is better.  Done.

> Why do you use hex for .uleb128 and decimal for .sleb128?

Because the old output_uleb128 and output_sleb128 routines
did the same thing when printing commentary.

> Should expand_call_to_function call assemble_external or mark_addressable?

Both will be done by expand_call.  The first via rtx_for_function_call,
the second after we discover the function isn't inlinable.

> ! /* ??? This is conceptually identical to expand_eh_region_end_allowed
> !    with an empty allowed list, but they are represented differently in
> !    the C++ LSDA.  */
> 
> This comment seems obsolete; the C++ semantics differ, as does how the two
> are handled in, say, eh_region_generates_edges.

The difference in C++ semantics would be handled by passing terminate
to the "failure" argument to expand_eh_region_end_allowed.  I'll clarify
the comment.

> This seems wrong.  Shouldn't the second be 'return 0' as well?  If the
> thrown type matches the catch type, it will be caught.

Doh!  Fixed.

> Thinking again about your proposed rethrow optimization, we can sometimes
> be sure that a rethrow will be caught (or satisfy an exception spec), but
> we can never be sure that it won't.

I scrapped the rethrow idea.  There is still a way to mark direct
throws only.  That's what you're seeing.

> !   /* ??? This comment was old before the most recent rewrite.  We
> !      really ought to fix the callers at some point.  */
>     /* For backwards compatibility, we allow callers to omit calls to
>        begin_protect_partials for the outermost region.  So, we must
>        explicitly do so here.  */
> 
> Did you try removing this?  I think C++ at least has been fixed.

Yes.  C++ has not been (entirely) fixed.

> Ordering of cleanups certainly does matter.  Or do you just mean that the
> order of the list doesn't matter, as something else will determine their
> order of execution?

When looking at the tree of cleanups, up-down order matters
(the chain through region->outer) not left-right (the chain
through region->next_peer).

Perhaps this is clearer:

     /* In the tree of cleanups, only outer-inner ordering matters.
        So link the children back in anywhere at the correct level.  */

> What's the difference between check_allowed and check_handled?  I think
> they are redundant.

They are only redundant with complete global knowledge of the type
heirarchy.  They return different values of I don't know.

> Please use "derived class" and "base class" instead of "subclass" and
> "superclass"; the latter terms are ambiguous, or at least have been used
> interchangeably in the literature.

Fixed.

> The current intersect_allowed would incorrectly return null for the first
> case and get the right answer for the second.  It's probably easiest to
> just keep a list of all the throw specs we've seen rather than trying to
> express that logic.

Hmm.  Just check all the nested specifications?  Works for me.

> Not true; the thrown type could be derived from both the catch type and an
> allowed type.

Oh, right.  Bother.

> So if we see a handler for a type which is a base of all the allowed types
> (or the rethrown type), we know that we will stop there just as for a
> catch-all handler.

Ok.

> There sure are a lot of functions that contain overlapping bits of the
> logic about when an exception can pass through to an outer handler.  I feel
> pretty strongly that we should contain all that (fairly complex) logic in a
> single function.

I'll see if I can rearrange things to make that happen.

> !      returns the block number of the next outermost region, if any. 
> 
> "containing region", perhaps?

You're looking at the wrong side of the diff.

> Existence.

Fixed.

Thanks for the review.


r~