------- 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
