Author: pluto                        Date: Fri Jun 24 11:39:31 2005 GMT
Module: SOURCES                       Tag: HEAD
---- Log message:
- fix ada fixed point wrong code.

---- Files affected:
SOURCES:
   gcc-pr22026.patch (NONE -> 1.1)  (NEW)

---- Diffs:

================================================================
Index: SOURCES/gcc-pr22026.patch
diff -u /dev/null SOURCES/gcc-pr22026.patch:1.1
--- /dev/null   Fri Jun 24 13:39:31 2005
+++ SOURCES/gcc-pr22026.patch   Fri Jun 24 13:39:26 2005
@@ -0,0 +1,101 @@
+Date: Thu, 23 Jun 2005 07:39:44 -0700
+From: Kazu Hirata <kazu at sethra dot codesourcery dot com>
+Subject: [patch] tree-vrp.c: Avoid VR_ANTI_RANGE in certain binary expression. 
(Take 2)
+
+Hi,
+
+Attached is a revised version of the patch posted at
+
+http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01729.html
+
+This version tries a bit harder not to drop to VR_VARYING right away
+when a binary expression involves VR_ANTI_RANGE.  Specifically, We
+drop to VR_VARYING only if a binary expression involving VR_ANTI_RANGE
+is PLUS_EXPR, MINUS_EXPR, or unsigned MULT_EXPR.  Other cases are left
+intact.
+
+The testcase has been updated to cover MINUS_EXPR and unsigned
+MULT_EXPR as well as PLUS_EXPR, which was already in the previous
+version of the testcase.
+
+Tested on x86_64-pc-linux-gnu.  OK to apply?
+
+Kazu Hirata
+
+2005-06-23  Kazu Hirata  <[EMAIL PROTECTED]>
+
+       PR tree-optimization/22026
+       * tree-vrp.c (extract_range_from_binary_expr): Drop to
+       VR_VARYING if a binary expression involving VR_ANTI_RANGE is
+       PLUS_EXPR, MINUS_EXPR, or unsigned MULT_EXPR.
+
+2005-06-23  Kazu Hirata  <[EMAIL PROTECTED]>
+
+       PR tree-optimization/22026
+       * gcc.dg/tree-ssa/pr22026.c: New.
+
+--- a/gcc/tree-vrp.c   21 Jun 2005 18:46:19 -0000      2.32
++++ b/gcc/tree-vrp.c   22 Jun 2005 20:33:01 -0000
+@@ -1100,6 +1100,19 @@ extract_range_from_binary_expr (value_ra
+          || code == MIN_EXPR
+          || code == MAX_EXPR)
+     {
++      /* If we have a PLUS_EXPR with two VR_ANTI_RANGEs, drop to
++       VR_VARYING.  It would take more effort to compute a precise
++       range for such a case.  For example, if we have op0 == 1 and
++       op1 == -1 with their ranges both being ~[0,0], we would have
++       op0 + op1 == 0, so we cannot claim that the sum is in ~[0,0].
++       Note that we are guaranteed to have vr0.type == vr1.type at
++       this point.  */
++      if (code == PLUS_EXPR && vr0.type == VR_ANTI_RANGE)
++      {
++        set_value_range_to_varying (vr);
++        return;
++      }
++
+       /* For operations that make the resulting range directly
+        proportional to the original ranges, apply the operation to
+        the same end of each range.  */
+@@ -1116,6 +1129,22 @@ extract_range_from_binary_expr (value_ra
+       tree val[4];
+       size_t i;
+ 
++      /* If we have an unsigned MULT_EXPR with two VR_ANTI_RANGEs,
++       drop to VR_VARYING.  It would take more effort to compute a
++       precise range for such a case.  For example, if we have
++       op0 == 65536 and op1 == 65536 with their ranges both being
++       ~[0,0] on a 32-bit machine, we would have op0 * op1 == 0, so
++       we cannot claim that the product is in ~[0,0].  Note that we
++       are guaranteed to have vr0.type == vr1.type at this
++       point.  */
++      if (code == MULT_EXPR
++        && vr0.type == VR_ANTI_RANGE
++        && (flag_wrapv || TYPE_UNSIGNED (TREE_TYPE (op0))))
++      {
++        set_value_range_to_varying (vr);
++        return;
++      }
++
+       /* Multiplications and divisions are a bit tricky to handle,
+        depending on the mix of signs we have in the two ranges, we
+        need to operate on different values to get the minimum and
+@@ -1181,7 +1210,20 @@ extract_range_from_binary_expr (value_ra
+     }
+   else if (code == MINUS_EXPR)
+     {
++      /* If we have a MINUS_EXPR with two VR_ANTI_RANGEs, drop to
++       VR_VARYING.  It would take more effort to compute a precise
++       range for such a case.  For example, if we have op0 == 1 and
++       op1 == 1 with their ranges both being ~[0,0], we would have
++       op0 - op1 == 0, so we cannot claim that the difference is in
++       ~[0,0].  Note that we are guaranteed to have
++       vr0.type == vr1.type at this point.  */
++      if (vr0.type == VR_ANTI_RANGE)
++      {
++        set_value_range_to_varying (vr);
++        return;
++      }
++
+       /* For MINUS_EXPR, apply the operation to the opposite ends of
+        each range.  */
+       min = vrp_int_const_binop (code, vr0.min, vr1.max);
================================================================
_______________________________________________
pld-cvs-commit mailing list
[email protected]
http://lists.pld-linux.org/mailman/listinfo/pld-cvs-commit

Reply via email to