Patch: gcj: fix for PR gcj/140

[Tom Tromey]

Tonight I looked at PR gcj/140.

It turns out that we generate different trees for `array.length' when
generating bytecode than we do when generating native code.  This is
apparently intentional.  So, I fixed the problem by changing
check_final_assignment to recognize the trees in both situations.

I successfully rebuilt libgcj (which involves byte-compiling all the
code) with this patch.

Ok to check in?

2000-03-31  Tom Tromey  <tromey@cygnus.com>

	* parse.y (check_final_assignment): Recognize assignments to the
	`length' field of an array when generating class files.

Tom

Index: parse.y
===================================================================
RCS file: /cvs/gcc/egcs/gcc/java/parse.y,v
retrieving revision 1.146
diff -u -r1.146 parse.y
--- parse.y	2000/03/23 07:01:24	1.146
+++ parse.y	2000/03/31 07:16:15
@@ -11402,10 +11423,16 @@
       && JDECL_P (TREE_OPERAND (lvalue, 1)))
     lvalue = TREE_OPERAND (lvalue, 1);
 
-  if (TREE_CODE (lvalue) == FIELD_DECL
-      && FIELD_FINAL (lvalue)
-      && !DECL_CLINIT_P (current_function_decl)
-      && !DECL_FINIT_P (current_function_decl))
+  /* When generating class files, references to the `length' field
+     look a bit different.  */
+  if ((flag_emit_class_files
+       && TREE_CODE (lvalue) == COMPONENT_REF
+       && TYPE_ARRAY_P (TREE_TYPE (TREE_OPERAND (lvalue, 0)))
+       && DECL_NAME (TREE_OPERAND (lvalue, 1)) == length_identifier_node)
+      || (TREE_CODE (lvalue) == FIELD_DECL
+	  && FIELD_FINAL (lvalue)
+	  && !DECL_CLINIT_P (current_function_decl)
+	  && !DECL_FINIT_P (current_function_decl)))
     {
       parse_error_context 
         (wfl, "Can't assign a value to the final variable `%s'",