PATCH: more Java evaluation order patches

[Per Bothner]

I just checked the following into egcs.  It fixes a couple of problems
relating to Java being stricter about evaluation order of sub-expressions
that C.  One problem I found was that fold_constant will re-write
	(A + (B, C))
into:
	(B, (A + C))
This may be valid for C, but breaks Java programs if B does a side-effect
that changes the value of A.  The simple fix was to just not call fold
if there is a side-effect in either operand.  It is possible that this
will cuases us to lose some valid optimizations;  I don't know.  A
better solution would be a way to annotate expression nodes that order
of side effects is important.

Tue Mar 16 15:15:41 1999  Per Bothner  <bothner@cygnus.com>

	* parse.y (java_complete_lhs):  Call force_evaluation_order
	after patch_newarray.
	(patch_binop):  Don't call fold if there are side effects.

Index: parse.y
===================================================================
RCS file: /cvs/cvsfiles/devo/gcc/java/parse.y,v
retrieving revision 1.43.2.54
diff -u -p -r1.43.2.54 parse.y
--- parse.y	1999/03/16 11:34:15	1.43.2.54
+++ parse.y	1999/03/17 00:16:24
@@ -7888,7 +7888,8 @@ java_complete_lhs (node)
       /* They complete the array creation expression, if no errors
          were found. */
       CAN_COMPLETE_NORMALLY (node) = 1;
-      return (flag ? error_mark_node : patch_newarray (node));
+      return (flag ? error_mark_node
+	      : force_evaluation_order (patch_newarray (node)));
 
     case NEW_CLASS_EXPR:
     case CALL_EXPR:
@@ -9285,7 +9286,10 @@ patch_binop (node, wfl_op1, wfl_op2)
   TREE_TYPE (node) = prom_type;
   TREE_SIDE_EFFECTS (node) = TREE_SIDE_EFFECTS (op1) | TREE_SIDE_EFFECTS (op2);
   
-  return fold (node);
+  /* fold does not respect side-effect order as required for Java but not C. */
+  if (! TREE_SIDE_EFFECTS (node))
+    node = fold (node);
+  return node;
 }
 
 /* Concatenate the STRING_CST CSTE and STRING. When AFTER is a non