This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Patch: gcj: fix for PR gcj/140
- To: Gcc Patch List <gcc-patches at gcc dot gnu dot org>
- Subject: Patch: gcj: fix for PR gcj/140
- From: Tom Tromey <tromey at cygnus dot com>
- Date: 31 Mar 2000 00:30:58 -0700
- Reply-To: tromey at cygnus dot com
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'",