]> git.pld-linux.org Git - packages/gcc.git/commitdiff
- fix ada fixed point wrong code.
authorPaweł Sikora <pluto@pld-linux.org>
Fri, 24 Jun 2005 11:39:26 +0000 (11:39 +0000)
committercvs2git <feedback@pld-linux.org>
Sun, 24 Jun 2012 12:13:13 +0000 (12:13 +0000)
Changed files:
    gcc-pr22026.patch -> 1.1

gcc-pr22026.patch [new file with mode: 0644]

diff --git a/gcc-pr22026.patch b/gcc-pr22026.patch
new file mode 100644 (file)
index 0000000..c85cd03
--- /dev/null
@@ -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  <kazu@codesourcery.com>
+
+       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  <kazu@codesourcery.com>
+
+       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);
This page took 0.117517 seconds and 4 git commands to generate.