[Bug tree-optimization/31169] Bootstrap comparison error at revision 122821

["rguenth at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #18 from rguenth at gcc dot gnu dot org  2007-03-16 09:25 -------
Gah, let's analyze the effect of this change.  First, with

  /* Refuse to operate on VARYING ranges, ranges of different kinds
     and symbolic ranges.  As an exception, we allow BIT_AND_EXPR
     because we may be able to derive a useful range even if one of
     the operands is VR_VARYING or symbolic range.  TODO, we may be
     able to derive anti-ranges in some cases.  */
  if (code != BIT_AND_EXPR
      && code != TRUTH_AND_EXPR
      && code != TRUTH_OR_EXPR
      && (vr0.type == VR_VARYING
          || vr1.type == VR_VARYING
          || vr0.type != vr1.type
          || symbolic_range_p (&vr0)
          || symbolic_range_p (&vr1)))
    {
      set_value_range_to_varying (vr);
      return;
    }

...

      /* If we have a RSHIFT_EXPR with a possibly negative shift
         count or an anti-range shift count drop to VR_VARYING.
         We currently cannot handle the overflow cases correctly.  */
      if (code == RSHIFT_EXPR
          && (vr1.type == VR_ANTI_RANGE
              || !vrp_expr_computes_nonnegative (op1, &sop)))
        {
          set_value_range_to_varying (vr);
          return;
        }

we make sure neither vr0 nor vr1 are anti-ranges and vr1 is >= 0.

Now, the hunk above changes us to not reject ranges that include zero for
the shift count.  (This makes it possible to handle unsigned half-ranges
[0, n])

If the count is actually zero, we can end up doing x << 0 (a left shift of
zero).  Does hppa handle this correctly?  Does it, for

int foo (unsigned int i)
{
  int j = 12048173;
  if (i < 32)
    {
      j = j >> i;
      if (j > 0)
        return 0;
    }
  return 1;
}

correctly have a value range of [0, 12048173] for j_5?  (look at 055t.vrp1
dump)

Obviously I fail to see how this can cause a miscompilation...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169