Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    In the sense that Java wants to use EH and things didn't just work.
    In the sense that every other EH aware language that uses EH in gcc
    (from gcc) will be hit by this same exact problem.

Unless they add the single line call to tell the core compiler that
they are EH-aware.

    Yes, and removing EH maintains backwards compatibility, but that is
    also irrelevant.  The question is, what are the natural semantics of
    existing tree codes in the presence of EH?  I will argue that they are
    those semanics when the flag is on.

You can argue that, and I no longer remember the full details to
refute you, but I do know that this was added for a reason, which I
believe was that a front-end that used cleanups but not EH would not
work properly without making a change to it and we don't want to make
to change front ends due to core compiler changes if we can avoid it.

    > Why change a default and require front ends to change because of it?

    Because it is what is best, it is what is natural and it is what is
    either explicitly stated or implied in the documentation.  

I disagree.

    In fact, Ada would require it be on also, if you just removed the parallel
    handling in the Ada frontend of cleanup actions and were content to
    let the backend generate code for you. 

There is no code to handle cleanups in the Ada front end; they are all
done by the core compiler.  The Ada front end does handle exceptions,
but in a way that does not involve the core compiler at all.  The
reason it does that was that it did so *before* the EH code was
written and was never modified to use that code once it was available.
Somebody is working on that project now, but it's very slow going.