Fwd: [JAVA, PATCH] PR java/8923: ICE when modifying a variable decleared "final static"

[Simon Martin]

Hi all.

Here's the revised patch I sent to gcc-patches@. It is a possible fix for the 
whole PR. I'm sorry to have forgotten java-patches@ in this mail and the 
previous one...

Best regards,
Simon

----------  Forwarded Message  ----------

Subject: Re: [JAVA, PATCH] PR java/8923: ICE when modifying a variable 
decleared "final static"
Date: Friday 28 July 2006 07:58
From: Simon Martin <simartin@users.sourceforge.net>
To: gcc-patches@gcc.gnu.org

Hi again.

[...]

> I haven't figured a fix for the initial test case yet:
>
> === cut here ===
> public class myBug
> {
>         final static int myConst = 200;
>
>         public static void bug() { myConst++;   /* ICE */ }
> }
> === cut here ===
>
> A good place to emit an error would be in check-init.c(check_init), because
> that's there that we get an error if myConst is not declared static. From
> my investigation, it looks like we currently don't see that myConst is
> final because it has been constant fold, and we get an INTEGER_CST. Is
> there a way to get back to the declaration from there? I guess that adding
> a check for INTEGER_CST in check_init would fix the problem, but I wonder
> if it's a "good" solution...

The attached patch completely solves the PR by calling 'java_complete_lhs'
instead of 'java_complete_tree' on the operand of '++' or '--' expression in
'java_complete_lhs'. This change guarantees that the operand will never be
resolved to its value. Thanks to this, check_init emits an error instead of
an ICE when we compile the PR's initial test case.

I also attach two test cases (they're not merged because the "1++" situation
is detected in the parser, whereas the "static final++" situation is detected
later on).

Boostrapped and regtested on i686-pc-linux-gnu. Is it OK? If so, could
 someone commit it for me?

Thanks in advance.

Best regards,
Simon

-------------------------------------------------------
-------------- next part --------------
2006-07-27  Simon Martin  <simartin@users.sourceforge.net>

	PR java/8923
	* parse.y (build_incdec): Emit an error instead of an ICE if '++' or '--'
	is used with a constant operand.
	(java_complete_lhs): When processing a '++' or '--' expression, don't call
	java_complete_tree but java_complete_lhs, so that a static final variable
	operand is never replaced by its value. This avoids an ICE later on.
	(patch_unaryop): Fixed typo in comment.
-------------- next part --------------
Index: java/parse.y
===================================================================
--- java/parse.y	(revision 115779)
+++ java/parse.y	(working copy)
@@ -12404,7 +12404,18 @@ java_complete_lhs (tree node)
 	 how to handle those cases. */
       wfl_op1 = TREE_OPERAND (node, 0);
       CAN_COMPLETE_NORMALLY (node) = 1;
-      TREE_OPERAND (node, 0) = java_complete_tree (wfl_op1);
+      if (TREE_CODE (node) == PREDECREMENT_EXPR
+	  || TREE_CODE (node) == PREINCREMENT_EXPR
+	  || TREE_CODE (node) == POSTDECREMENT_EXPR
+	  || TREE_CODE (node) == POSTINCREMENT_EXPR)
+	{ /* We don't want static finals to be resolved to their value
+	     to avoid ICEing later. It solves PR8923. */
+	  TREE_OPERAND (node, 0) = java_complete_lhs (wfl_op1);
+	}
+      else
+	{
+	  TREE_OPERAND (node, 0) = java_complete_tree (wfl_op1);
+	}
       if (TREE_OPERAND (node, 0) == error_mark_node)
 	return error_mark_node;
       node = patch_unaryop (node, wfl_op1);
@@ -14223,6 +14234,14 @@ build_incdec (int op_token, int op_locat
   /* Store the location of the operator, for better error report. The
      string of the operator will be rebuild based on the OP value. */
   EXPR_WFL_LINECOL (node) = op_location;
+
+  /* Report an error if the operand is a constant. */
+  if (TREE_CONSTANT (op1)) {
+    parse_error_context (node, "%qs cannot be used with a constant",
+                         operator_string (node));
+    return error_mark_node;
+  }
+
   return node;
 }
 
@@ -14377,7 +14396,7 @@ patch_unaryop (tree node, tree wfl_op)
 	  error_found = 1;
 	}
 
-      /* From now on, we know that op if a variable and that it has a
+      /* From now on, we know that op is a variable and that it has a
          valid wfl. We use wfl_op to locate errors related to the
          ++/-- operand. */
       if (!JNUMERIC_TYPE_P (op_type))
-------------- next part --------------
class pr8929_1
{
    public pr8929_1()
    {
        1++;
        1--;
    }
}
-------------- next part --------------
class pr8929_2
{
    private static final int statFinalI = 0;
    private final int notStatFinalI = 0;
    public pr8929_2()
    {
        final int i = 0; i++;
        notStatFinalI++;
        statFinalI++;
    }
}