This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Eliminating Assembler Already Defined Messages for Java Library
The following patch allows a bootstrap to complete. I haven't done any
other testing, but I'm about to try to build Kawa with it.
This patch takes the path of enabling x_whole_function_mode_p. This causes
other things to break, hence the other changes.
I commented out some code that checks that final fields are correctly
set. This seems to break the bootstrap because the code is run *after*
expand is run, and my guess it is related to the BLOCK_SUBBLOCKS/
BLOCK_EXPR_BODY pun. I didn't want to try Mark's suggestion of using
TREE_TYPE for BLOCK_EXPR_BODY because that gets into an issue where
we treat a BLOCK as an expression, and expressions have types.
Note I have disabled some error checks for assigning to final
variables. I don't really have a feel for which errors will now slip
through, because I cannot understand the logic behind the code. More
importantly, I don't see how it can possibly do the right thing, which
is to check for "definite assignment" and "definite unnassignment" as
defined in the (revised) language spec; the existing code seems to do
something completely different. The checks need to be replaced by
code that uses the framework in check-init.c.
It may be possible to re-enable the error checks if we get rid of the
BLOCK_SUBBLOCKS/BLOCK_EXPR_BODY pun. Using BIND_EXPR instead of BLOCK
seems the best way to do that.
I haven't checked this in, but will (in teh trunk) unless there
are objections.
2001-03-13 Per Bothner <per@bothner.com>
* expr.c (java_lang_expand_expr): Use expand_start_bindings_and_block.
* parse.y (source_end_java_method): Do poplevel etc before expand.
Set x_whole_function_mode_p flag.
(java_complete_expand_methods): Comment out calls to
check_{static_,}final_variable_global_assignment_flag - breaks
building libjava, and should be re=written anyway.
Index: expr.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/expr.c,v
retrieving revision 1.103
diff -u -p -r1.103 expr.c
--- expr.c 2001/02/16 22:31:52 1.103
+++ expr.c 2001/03/13 23:06:49
@@ -2438,7 +2438,7 @@ java_lang_expand_expr (exp, target, tmod
tree local;
tree body = BLOCK_EXPR_BODY (exp);
pushlevel (2); /* 2 and above */
- expand_start_bindings (0);
+ expand_start_bindings_and_block (0, exp);
local = BLOCK_EXPR_DECLS (exp);
while (local)
{
Index: parse.y
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/parse.y,v
retrieving revision 1.258
diff -u -p -r1.258 parse.y
--- parse.y 2001/02/24 03:28:39 1.258
+++ parse.y 2001/03/13 23:06:58
@@ -7171,17 +7171,24 @@ source_end_java_method ()
if (BLOCK_EXPR_BODY (DECL_FUNCTION_BODY (fndecl)) == empty_stmt_node)
BLOCK_EXPR_BODY (DECL_FUNCTION_BODY (fndecl)) = NULL_TREE;
+ /* pop out of its parameters */
+ pushdecl_force_head (DECL_ARGUMENTS (fndecl));
+ poplevel (1, 0, 1);
+ BLOCK_SUPERCONTEXT (DECL_INITIAL (fndecl)) = fndecl;
+
+ if (! flag_syntax_only) /* i.e. not just emitting class files. */
+ {
+ /* This function is being processed in whole-function mode. */
+ cfun->x_whole_function_mode_p = 1;
+ DECL_INITIAL (fndecl) = DECL_FUNCTION_BODY (fndecl); /* Needed? FIXME */
+ }
+
/* Generate function's code */
if (BLOCK_EXPR_BODY (DECL_FUNCTION_BODY (fndecl))
&& ! flag_emit_class_files
&& ! flag_emit_xref)
expand_expr_stmt (BLOCK_EXPR_BODY (DECL_FUNCTION_BODY (fndecl)));
- /* pop out of its parameters */
- pushdecl_force_head (DECL_ARGUMENTS (fndecl));
- poplevel (1, 0, 1);
- BLOCK_SUPERCONTEXT (DECL_INITIAL (fndecl)) = fndecl;
-
/* Generate rtl for function exit. */
if (! flag_emit_class_files && ! flag_emit_xref)
{
@@ -7513,7 +7520,11 @@ java_complete_expand_methods (class_decl
&& verify_constructor_circularity (decl, decl))
break;
+#if 0
/* Final check on the initialization of final variables. */
+ /* We can't do this after expand because BLOCK_SUBBLOCK
+ * has smashed BLOCK_DECL_BODY. In any case the code to check
+ * final variables needs to be re-written to use check-init. FIXME */
if (TYPE_HAS_FINAL_VARIABLE (current_class))
{
check_final_variable_global_assignment_flag (current_class);
@@ -7521,6 +7532,7 @@ java_complete_expand_methods (class_decl
if (CLASS_INTERFACE (class_decl))
check_static_final_variable_assignment_flag (current_class);
}
+#endif
/* Save the constant pool. We'll need to restore it later. */
TYPE_CPOOL (current_class) = outgoing_cpool;
Mark Mitchell <mark@codesourcery.com> writes:
> >>>>> "Per" == Per Bothner <per@bothner.com> writes:
>
> Per> The problem involves a block created by expand_fixup. This
> Per> needs to be inserted somehow into the block structure - but
> Per> where? Some complicating factors:
>
> Right. Globally, I think that expand_fixup has no business doing
> this. All tree structure should be created by the front-end; that
> tree->RTL conversion is generating a BLOCK is rather grotesque -- but
> I never got around to figuring out how to avoid that.
>
> Per> * cfun->x_whole_function_mode_p is not set. It perhaps
> Per> should be (when compiling from source). However, the Java
>
> Yes, I think it should be. As per the documentation:
>
> /* Nonzero if this function is being processed in function-at-a-time
> mode. In other words, if all tree structure for this function,
> including the BLOCK tree, is created before RTL generation
> commences. */
>
> I believe this is true for the Java front-end.
>
> Per> * jc1 uses a pun where the BLOCK_SUBBLOCKS field of a block
> Per> is used for the BLOCK_EXPR_BODY of a block (i.e. the "body"
> Per> expression of a block, typically a OCMPOUND_EXPR). The
> Per> BLOCK_EXPR_BODY is used after parsing and up until
> Per> expand_expr; BLOCK_SUBBLOCKS field needs to be correct at
> Per> final. I don't know if this is an issue, but it could be a
> Per> contributing complicating factor.
>
> Indeed. This is probably a bad idea; I would suggest using the
> TREE_TYPE of the block instead, perhaps -- that is (I think) unused
> for a BLOCK. If so, we should document in tree.def that this field is
> free for use by front-ends.
>
> Per> So before we try to hack together a solution, we need to
> Per> understand / agree on some things:
>
> Per> (1) is setting x_whole_function_mode_p to 1 the Right Think
> Per> to do?
>
> I think so.
>
> Per> (2) Given that we have a tree of BLOCK nodes created by the
> Per> front end, when expand_fixup creates a block, where should it
> Per> go? The code for when cfun->x_whole_function_mode_p is true
> Per> is this: BLOCK_CHAIN (block) = BLOCK_CHAIN (DECL_INITIAL
> Per> (current_function_decl)); BLOCK_CHAIN (DECL_INITIAL
> Per> (current_function_decl)) = block; This doesn't work, because
> Per> DECL_INITIAL hasn't been set yet, but that can be fixed.
>
> That's a tricky bit of logic -- but I think it's correct. Basically,
> it shouldn't matter where the new BLOCK goes because reorder_blocks is
> supposed to make a nice block-tree out of what's actually in the
> instruction stream.
>
> --
> Mark Mitchell mark@codesourcery.com
> CodeSourcery, LLC http://www.codesourcery.com
>
--
--Per Bothner
per@bothner.com http://www.bothner.com/~per/