Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[Richard Kenner]

    Yes, but why should they?  Imagine n new languages and 2 old
    languages.  If n is > 2, it is more work.  

That's an odd way of counting work.  I count adding one line to new code as a
negligable amount of work.  But handling the confusion resulting from not
being able to have a single front end work with both the old and new version
of the compiler an extraordinary cost, distributed to many of the potential
users of the compiler.

    I think there is a miscommunication.  In expand_decl_cleanup type of
    things, which seem to be used by the Ada front end, else there
    wouldn't be a need for this flag, those actions are what I refer to
    when I say cleanup.  Upon an exception I think the Ada spec says these
    actions are performed in a certain order and so on when an exception
    happens.  In order for them to happen, you walk a list at run time and
    perform actions off the list.  This is the code I refer to. 

Those are used both for EH and non-EH purposes!  Cleanups are also run when a
block is exited via a jump out of the block.  There's nothing in the
documentation that says that you have to use EH if you want to force an
action to be done when a block is exited either by a jump or by falling
through.  More to the point, that use of cleanups *predated* the EH code, as
I said before, so the EH code had the effect of breaking it for compilers
that just wanted that use as a cleanup.  My change fixed that and you are
proposing to break it again.

    This is as I recall handled by the Ada front end.  Maybe they only
    express themselves in the language under the guise of exception
    handling (try finally)?

No, that's quite wrong. The cleanup actions are added by the Ada front end as
part of the "expander" process, which works on tree nodes and transforms them
into constructs of a lower semantic level (such as inserting calls to library
function).  The part of the front end that deals with cleanup actions is one
of the most complex parts of it and one I don't understand very well, but I
do know that they have nothing to do with exceptions at the source level:
they are generated from constructs that use tasking, dynamic allocation, and
controlled types, among other things.

    After the Ada front end is converted, you will understand what I meant
    by replicated code.

The only "replicated code" is that the front end calls the builtin setjmp and
longjmp directly.  This has nothing to do with cleanup actions.  The actual
list of things that need to be done when an exception occurs is handled
outside this entire mechanism and done via library functions since the Ada
language requires a very precise set of semantics for such actions, so they
can't be dealt with using a static nesting of cleanups that the core compiler
provides.

Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[David Edelsohn]

>>>>> Per Bothner writes:

Per> Thanks Mike Stump pointing me in the right direction, I successfully
Per> re-wrote the implementation of the Java "synchronized"
Per> statement to use CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR.
Per> That new code is now in egcs.  The re-write fix a serious
Per> problem we were experiencing.

Per> I haven't re-written the try/finally statement, but I intend
Per> to do that as well.

	Did this turn out to follow the C++ constructor/destructor
semantics as Joe Buck suggested?  I'm just curious from the examples in
your and Joe Buck's messages, which semantics were appropriate for Java.


Thanks, David

Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[Per Bothner]

Thanks Mike Stump pointing me in the right direction, I successfully
re-wrote the implementation of the Java "synchronized"
statement to use CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR.
That new code is now in egcs.  The re-write fix a serious
problem we were experiencing.

I haven't re-written the try/finally statement, but I intend
to do that as well.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[Richard Stallman]

      Unfortuantely, I no longer remember the
    details, but the problem occurs in a front end that uses cleanup items
    (not via tree cods but via calls to expand_decl_cleanup) but does not
    call the recently-added EH functions.  Such front ends will blow up
    (if I remember correctly) without my change.

I see.

In this case, I think I don't have an opinion on the question of which
way should be the default.

Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[Richard Kenner]

    Why does the question affect these front ends?  It can only be
    because GCC output code, in certain cases, to support error handling,
    even in functions that don't use error handling constructs.

    Why would GCC do that?  Surely because that code is needed to make
    these functions interoperate properly with the use of EH in other
    functions.

No, that's not correct.  Unfortuantely, I no longer remember the
details, but the problem occurs in a front end that uses cleanup items
(not via tree cods but via calls to expand_decl_cleanup) but does not
call the recently-added EH functions.  Such front ends will blow up
(if I remember correctly) without my change.  My change means that if
a front end calls EH functions, it must first call a function at its
initialization time that declares its intention to do so.

Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[Richard Stallman]

    No question about that!  The issue here was front ends that *do not* use
    the EH tree codes.

Why does the question affect these front ends?  It can only be
because GCC output code, in certain cases, to support error handling,
even in functions that don't use error handling constructs.

Why would GCC do that?  Surely because that code is needed to make
these functions interoperate properly with the use of EH in other functions.

In such a case, GCC should do that for all languages, even languages
that have no EH constructs of their own.  Because those languages
should interoperate properly with the languages that do have EH constructs.

CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[mal]

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

Modula-3 has the same try-finally construct and the language supports
threads so they have the same problems as Java. Their current compiler
has a gcc front end so you could check what they did.

HTH

Lieven

Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[Richard Kenner]

    I agree.  The goal is to make the EH facilities of GCC usable for all
    languages.  So the feature should always be "on".  If a program uses
    the EH tree codes, they should do their job.

No question about that!  The issue here was front ends that *do not* use
the EH tree codes.

Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[Richard Stallman]

    > That was set up so that a front end that wanted to use EH had to
    > call a function in order to do it.

    Which is wrong.  A language that emits tree codes that map to EH
    constructs should just work because the documented semantics of those
    tree codes demand it.

I agree.  The goal is to make the EH facilities of GCC usable for all
languages.  So the feature should always be "on".  If a program uses
the EH tree codes, they should do their job.

Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[Mike Stump]

> Date: Fri, 18 Dec 98 19:40:43 EST
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)

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

Yes, but why should they?  Imagine n new languages and 2 old
languages.  If n is > 2, it is more work.  I hope we have more than
two new languages.  Java appears to be 1 (if Per confirms this is why
we was misled).

>     > 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.

Could you state why.  I have tried to support my position.  To quote
the documentation:

/* CLEANUP is an expression to be executed at exit from this binding contour;
   for example, in C++, it might call the destructor for this variable.

   We wrap CLEANUP in an UNSAVE_EXPR node, so that we can expand the
   CLEANUP multiple times, and have the correct semantics.  This
   happens in exception handling, for gotos, returns, breaks that
   leave the current scope.

int
expand_decl_cleanup (decl, cleanup)
     tree decl, cleanup;

Now, we can argue what it means to exit the binding contour.  Feel
free to say that if we leave it via an exception, we don't really
leave it...  I'm not ever going to accept that.

> There is no code to handle cleanups in the Ada front end;

I think there is a miscommunication.  In expand_decl_cleanup type of
things, which seem to be used by the Ada front end, else there
wouldn't be a need for this flag, those actions are what I refer to
when I say cleanup.  Upon an exception I think the Ada spec says these
actions are performed in a certain order and so on when an exception
happens.  In order for them to happen, you walk a list at run time and
perform actions off the list.  This is the code I refer to.  This is
as I recall handled by the Ada front end.  Maybe they only express
themselves in the language under the guise of exception handling (try
finally)?

After the Ada front end is converted, you will understand what I meant
by replicated code.

Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[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.

Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[Mike Stump]

> Date: Fri, 18 Dec 98 18:22:20 EST
> From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)

>     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.

> I'm confused here.  In what sense is the default "wrong"?

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.

A language that works within the design of gcc should just work, they
should not need to ask the backend to do something special to just
work.  Languages that want to do something funny behind gcc's back are
the odd ones out, we should not cater to them.  Because they don't use
gcc the way in which gcc was meant to be used, it should be up to them
to disable otherwise natural and expected behavior.

> That was set up so that a front end that wanted to use EH had to
> call a function in order to do it.

Which is wrong.  A language that emits tree codes that map to EH
constructs should just work because the documented semantics of those
tree codes demand it.

> That maintains backwards compatibility.

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.

> 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.  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.  It is only because Ada has
replicated functionality and replicated code in its frontend (which is
wrong), that Ada needed this hack in the first place.  The hack is a
hack, and the default of the hack should cater to those languages that
don't need the hack; only languages that need the hack should be
inconvenienced.

Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[Richard Kenner]

    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.

I'm confused here.  In what sense is the default "wrong"?  That was
set up so that a front end that wanted to use EH had to call a
function in order to do it.  That maintains backwards compatibility.
Why change a default and require front ends to change because of it?

Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[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.

Re: CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[Joe Buck]

> 
> I am working on a try-finally type construct.  Specifically,
> I am trying to implement the Java synchronized statement.
> This has the form:
> 	synchronized (OBJ) { BODY }
> It is equivalent to ...
> 	tmp = OBJ;
> 	_Jv_MonitorEnter(tmp);
> 	try {
> 	  BODY
> 	  _Jv_MonitorExit(tmp);
> 	} catch (...) {
> 	  _Jv_MonitorExit(tmp);
> 	  throw;
> 	}

In C++ I would write simply

    {
	Jv_CriticalRegion monitor(OBJ);
	BODY;
    }

The idea is that Jv_CriticalRegion is a class with a constructor and a
destructor and one member, tmp.  The constructor does _Jv_MonitorEnter and
the destructor does _Jv_MonitorExit.

e.g.

class Jv_CriticalRegion {
public:
	JvCriticalRegion(Object OBJ) : tmp(OBJ) {
		_Jv_MonitorEnter(tmp);
	}
	~JvCriticalRegion() {
		_Jv_MonitorExit(tmp);
private:
	Object tmp;
};


The key is that the destructor is always called, whether BODY
exits successfully or it throws an exception.

> 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.

It would seem that the thing to do is to look at how the C++ front
end sets up destructors, and set up your call to _Jv_MonitorExit
in the same way.

CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR vs TRY_CATCH_EXPR

[Per Bothner]

I am working on a try-finally type construct.  Specifically,
I am trying to implement the Java synchronized statement.
This has the form:
	synchronized (OBJ) { BODY }
It is equivalent to:
	tmp = OBJ;
	_Jv_MonitorEnter(tmp);
	try {
	  BODY
	} finally {
	  _Jv_MonitorExit(tmp);
	}
which is equivalent to the C++:
	tmp = OBJ;
	_Jv_MonitorEnter(tmp);
	try {
	  BODY
	  _Jv_MonitorExit(tmp);
	} catch (...) {
	  _Jv_MonitorExit(tmp);
	  throw;
	}

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.

The tree code CLEANUP_POINT_EXPR+WITH_CLEANUP_EXPR and/or TRY_CATCH_EXPR
look like they should do the right thing, but they don't seem to.
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?  I would assume so,
but the comments in tree.def don't specifically say, and the code
(in egcs) doesn't seem to handle it.  However, this could easily
be bit-rot 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.  I suspect they are only
used by Ada, which is not integrated into egcs.
(2)  Is a cleanup specified with CLEANUP_POINT_EXPR supposed 
to be executed if there is a jump (or return) out of the BODY?
This I'm more confident about that the answer is "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.
(4) If there is a jump out of the first operand of TRY_CATCH_EXPR,
is the second operand evaluated?  I assume not.

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.
But before I bug the exception handling people, I'd like to verify
that my understanding is correct.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner