This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: ia64 c++ abi exception handling


>>>>> "Richard" == Richard Henderson <rth@redhat.com> writes:

    Richard> The following is an initial implementation of the
    Richard> exception handling model proposed by the multi-vendor C++
    Richard> ABI folks.  The specification is targeted at IA-64, but
    Richard> require only minor tweeks to be usable on other targets.

I'm really glad this work is going to get done.  This is one of the
(few) good things about how long it's taking to get 3.0 out -- this is
really great functionality to have.

    Richard> FAIL: g++.eh/cond1.C (test for excess errors) FAIL:
    Richard> g++.eh/crash5.C (test for excess errors) FAIL:
    Richard> g++.other/cond5.C (test for excess errors)

    Richard>    `({...})' has type `void' and is not a
    Richard> throw-expression

    Richard>    Before the front end somehow magically recognized a
    Richard> post-template expansion throw expression.  The new code
    Richard> doesn't look the same, and I'm not sure how to update the
    Richard> check.

I'm not sure what you mean.  THROW_EXPRs should be treated exactly the
same until cplus_expand_expr, which happens during tree->rtl
conversion.  If your patch changes the C++ front-end's tree
representation, that's probably a bad thing.  If it doesn't, I don't
see how the front-end would know to issue this error message.

Yes, I think that's what's wrong.  In build_throw you do a lot of work
that should really be done in cplus_expand_expr, I think.  The idea is
to keep things at a relatively high-level until expansion time.  Or,
perhaps, until tree-optimization time.  In any case, not right up
front.  (Ideally, I would eventually like to build a representation
that is unlowered C++, then lower it to C-plus-magic, then optimize
it, then generate RTL.)

I'm not going to have a chance to look at your patch right away; I
hope Jason can.  The change to current_binding_level looks suspicious
to me.  Also, you've still got a comment about partial-array
construction in except.c; is that still a problem?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]