Re: libjava build failure sol2.6 asm problem?

[Jeff Sturm <jsturm at one-point dot com>]

On Sat, 29 Dec 2001, Per Bothner wrote:
> Basically simplification and consistency.  Some parts of gcc/java had
> been using CLEANUP_POINT_EXPR and WITH_CLEANUP_EXPR and some parts had
> been using TRY_FINALLY_EXPR, without much reason.  I fixed a problem
> in jcf-write.c for TRY_FINALLY_EXPR, but because of the duplication we
> also needed the same fix for CLEANUP_POINT_EXPR and WITH_CLEANUP_EXPR.
> Rather than do that, it seemed better to just use TRY_FINALLY_EXPR,
> which is simpler and closer to Java semenantics.

I see.  Thanks.

> Well, I have no strong feeling on how TRY_FINALLY_EXPR is implemented,
> and I understand that functionality of GOTO_SUBROUTINE_EXPR may be
> probelemtical on some architectures.

True.  But tree.def also says:

   TRY_FINALLY_EXPR should be used when the cleanup is actual statements
   in the source of the current function (which people might want to
   set breakpoints in).  */

So if I understand correctly there is a good motivation to not emit
cleanup blocks twice, though that's not important for java "synchronized"
blocks.

> However, the basic functionality
> of "save following address in a given register and then jump to a given
> label;  later return to the saved address" *is* needed at the Java
> bytecode level to implement the jsr/ret bytecode instructions.

It may be helpful here if the backend could easily emit the equivalent
instructions, e.g. a bsr/ret on Alpha, without a new call frame.  The code
we generate now is longer and PIC doesn't come for free.

However the c++ frontend doesn't bother with TRY_FINALLY_EXPR, it emits
even inlined destructors twice.  So I'm inclined to say gcj should do the
same.

(I'm still puzzled why the return_address label gets deleted on some
targets and not others... I suspect there's a bug lurking somewhere, but
I've given up looking for now.)

Jeff