Parser bug

Alexandre Petit-Bianco apbianco@cygnus.com
Mon Apr 12 18:41:00 GMT 1999


MoT writes:
> Here is a little patch that *seems* to fix the problem I've
> reported.

Unfortunately, it doesn't work when generating class files (where an
ARRAY_REF is always used) and since it tries to fix the array
references coming in the form of a COMPOUND_EXPR to early, it misses
reporting errors when the type of the array references isn't a
primitive type.

The thing is that right now, an array reference will be altered in
different ways depending on whether we do bounds checking, generate
class files and/or side effects in the expressions should be taken
into account. It roughly breaks down into something like:

We have side effects:

	Bounds check			No bounds check
Class	ARRAY_REF                       ARRAY_REF
Native  COMPOUND_EXPR -+- ...           COMPOUND_EXPR -+- ...
                       `  INDIRECT_REF                  ` INDIRECT_REF

We don't have side effects:

	Bounds check			No bounds check
Class	ARRAY_REF                       ARRAY_REF
Native	INDIRECT_REF                    INDIRECT_REF

You can see the effect of this (fragile) analysis at some other places
in the code and it's quite frankly becoming unmanageable (as we also
think of introducing a NULL pointer check) and will probably bite us
again in the future.

So the plan is to introduce a new Java tree node (JAVA_ARRAY_REF) and
to defer to java_lang_expand_expr the creation of various wrapper
around the INDIRECT_REF to ensure: array bounds checking, NULL pointer
check and run-time check for ArrayStore exceptions. It will also take
care of the side effects in the expression and manage things that
should be evaluated only once and will also have the advantage of
feeding the native and bytecode backends with the same tree structure.

For now, further hacking was necessary to get things right. I just
checked in the following patch, and verified that it works.

Thanks for your contribution.

.--- Alex (www.cygnus.com/~apbianco, {apbianco-page,apbianco}@cygnus.com)
| NT? Not Today, Not Tomorrow, No Thanks.

	* parse.y (patch_unaryop): Fix ++ operator check on array
 	references.

Index: parse.y
===================================================================
RCS file: /egcs/carton/cvsfiles/egcs/gcc/java/parse.y,v
retrieving revision 1.73
diff -u -p -r1.73 parse.y
--- parse.y	1999/04/09 16:26:33	1.73
+++ parse.y	1999/04/13 01:18:01
@@ -9742,10 +9742,14 @@ patch_unaryop (node, wfl_op)
       /* 15.14.2 Prefix Decrement Operator -- */
     case PREDECREMENT_EXPR:
       decl = strip_out_static_field_access_decl (op);
+      /* We really should have a JAVA_ARRAY_EXPR to avoid this */
       if (!JDECL_P (decl) 
-	  && !((TREE_CODE (decl) == INDIRECT_REF 
-		|| TREE_CODE (decl) == COMPONENT_REF) 
-	       && JPRIMITIVE_TYPE_P (TREE_TYPE (decl))))
+	  && TREE_CODE (decl) != COMPONENT_REF
+	  && !(flag_emit_class_files && TREE_CODE (decl) == ARRAY_REF)
+	  && TREE_CODE (decl) != INDIRECT_REF
+	  && !(TREE_CODE (decl) == COMPOUND_EXPR
+	       && TREE_OPERAND (decl, 1)
+	       && (TREE_CODE (TREE_OPERAND (decl, 1)) == INDIRECT_REF)))
 	{
 	  tree lvalue;
 	  /* Before screaming, check that we're not in fact trying to



More information about the Java mailing list