Re: libjava build failure sol2.6 asm problem?

[Per Bothner <per at bothner dot com>]

Jeff Sturm wrote:


> I've isolated it to this patch, in gcc/java:
> 
> 2001-12-03  Per Bothner  <per@bothner.com>
> 
>    * decl.c (complete_start_java_method):  Now generate TRY_FINALLY_EXPR
>    instead of CLEANUP_POINT_EXPR and WITH_CLEANUP_EXPR.
>    * jcf-write.c (generate_bytecode_insns):  Remove support for
>    CLEANUP_POINT_EXPR and WITH_CLEANUP_EXPR as they are no longer used.
>    * check-init.c (check_init):  Likewise.
> 
> Generating a TRY_FINALLY_EXPR causes a GOTO_SUBROUTINE_EXPR.  In expr.c:
> 
>     case GOTO_SUBROUTINE_EXPR:
>       {
>         rtx subr = (rtx) TREE_OPERAND (exp, 0);
>         rtx return_link = *(rtx *) &TREE_OPERAND (exp, 1);
>         rtx return_address = gen_label_rtx ();
>         emit_move_insn (return_link,
>                         gen_rtx_LABEL_REF (Pmode, return_address));
> 
> So that's how we get to gen_movsi_pic_label_ref.  Not understanding the
> reason for this patch,


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.

> should I modify TRY_FINALLY_EXPR/GOTO_SUBROUTE_EXPR
> to work more like CLEANUP_POINT_EXPR/WITH_CLEANUP_EXPR?  I.e. without
> generating a move from a LABEL_REF?


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.  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.  However, 
note that the bytecode compiler uses build_java_jsr in java/expr.c,
which does not actually use GOTO_SUBROUTINE_EXPR.  That is because the
former needs to use trees, while the latter uses a hybrid tree/rtx
kludge (because the mid-end uses cleanup expressions).  Note also that
the byetcode parser cannot generate either TRY_FINALLY_EXPR or
CLEANUP_POINT_EXPR+WITH_CLEANUP_EXPR, because neither concept exists at
the bytecode level.

In other words:  It seems to me that we do need to support the
functionality of GOTO_SUBROUTINE_EXPR, though the actual implementation
(and perhaps the interface) may be wrong.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/