Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[mrs at wrs dot com (Mike Stump)]

> Date: Fri, 18 Dec 1998 10:52:09 -0800
> From: Per Bothner <bothner@cygnus.com>

> I am working on a try-finally type construct.  Specifically,
> I am trying to implement the Java synchronized statement.

> which is equivalent to the C++:
> 	tmp = OBJ;
> 	_Jv_MonitorEnter(tmp);
> 	try {
> 	  BODY
> 	  _Jv_MonitorExit(tmp);
> 	} catch (...) {
> 	  _Jv_MonitorExit(tmp);
> 	  throw;
> 	}

Are you sure?  Do you want to run the exit routine again from the top
when the exit routine throws, but only if we didn't throw originally?
I can't imagine you want those semantics.

Instead, I'm going to guess that you either want to rethrow to the
outer context, or that exit never throws, or you want to reexit when
exit throws (in all cases).

> So I'm trying to express this using existing gcc tree node types,
> and having no luck.  The complications are that the finalization
> expression (this this case _Jv_MonitorExit(tmp)) need to be done
> after any of:
> (a) BODY completes normally.
> (b) there is a return, break, or continue that exits BODY.
> (c) there is an unhandled exception thrown by BODY.

Ah, yes, this doesn't match the C++ code above, as I suspected.  (Or
it is incomplete.)  Sounds like a WITH_CLEANUP_EXPR to me.

> The tree code CLEANUP_POINT_EXPR+WITH_CLEANUP_EXPR and/or TRY_CATCH_EXPR

No, stay away from TRY_CATCH_EXPR, unless you want differing semantics
in the throw case.

> The first question is what are these forms *supposed* to do?

> (1) Is a cleanup specified with CLEANUP_POINT_EXPR supposed to be
> executed if an unhandled exception is thrown?

Yes.

> I would assume so, but the comments in tree.def don't specifically
> say,

The wording is horrible.  It was meant to say that.

Kenner put in using_eh_for_cleanups_p so Ada can avoid EH in gcc,
(ick, hack, coff).  He choose the wrong default for it, it should
default to on.  This is a bug and can be fixed in egcs.  Once you set
it, you'll notice everything just works.

> and the code
> (in egcs) doesn't seem to handle it.  However, this could easily
> be bit-rot

No, it is not bit rotted.

> left over from re-writing the exception handling code,
> since as far as I know CLEANUP_POINT_EXPR+WITH_CLEANUP_EXPR don't
> seem to be used by any egcs front-end.

WITH_CLEANUP_EXPR was used by C++ it has been replaced by TARGET_EXPR,
they largly overlap.  If we did tree maintenance, we would unify and
fix the semantics and eliminate the duplicate.

TARGET_EXPR may also has the `right' semantics for you.
CLEANUP_POINT_EXPR is in fact used by C++.

> (2)  Is a cleanup specified with CLEANUP_POINT_EXPR supposed 
> to be executed if there is a jump (or return) out of the BODY?

Yes.

> (3) If an exception is thrown by the first operand of TRY_CATCH_EXPR,
> is it re-thrown after the second operand is executed?  I assume
> so, and it seems to be the case.

Yes, that is the only obvious semantic, and it happens for you.

> (4) If there is a jump out of the first operand of TRY_CATCH_EXPR,
> is the second operand evaluated?  I assume not.

No.  From the doc:

   This differs from WITH_CLEANUP_EXPR, in that operand 2 is never
   evaluated unless an exception is throw.

> My guess is that what I should be using is:
> 	build1 (CLEANUP_POINT_EXPR, void_type_node,
>                 build (WITH_CLEANUP_EXPR, void_type_node, 
>                        BODY, NULL_TREE,
> 		       build (CALL_EXPR, ... "_Jv_MonitorExit" ..., tmp)));

> However, the implementation of CLEANUP_POINT_EXPR+WITH_CLEANUP_EXPR
> is broken and needs to be fixed for the new correct exception handling.

No, it's not broke, don't fix it.  You might need to enable it (see
above).

> But before I bug the exception handling people,

Oh, you mean I shouldn't have answered?


Give it a try and let me know if you get it to work.  If you can't be
more specific about what doesn't happen and exactly what you want.