Eliminating Assembler Already Defined Messages for Java Library

Tue Mar 13 15:25:00 GMT 2001

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/
