On Mon, Oct 19, 2020 at 12:44 PM Jakub Jelinek <ja...@redhat.com> wrote:
>
> On Mon, Oct 19, 2020 at 12:36:24PM +0200, Aldy Hernandez via Gcc-patches 
> wrote:
> > The test is trying to shift by 129, but the underlying type is 128 bits.
> > This causes low_bits to wrap around to -1 and things go bad really
> > quick.
> >
> > Attached is my proposed solution.
> >
> > Andrew, do you have a preference on how to fix this?
>
> Shifts are undefined already when the shift count is equal to the precision.
> And arbitrarily choosing one of the values as the shift count seems risky to
> me (and even when used, the most natural would be truncating the excess bits
> rather than saturating), can't it just punt (return VARYING) for the UB
> shifts?

Good point.  It looks cleaner too.

How about this?

diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 30d2a4d3987..0ab5e62be7f 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -1579,6 +1579,9 @@ operator_lshift::op1_range (irange &r,
       wide_int shift = wi::to_wide (shift_amount);
       if (wi::lt_p (shift, 0, SIGNED))
        return false;
+      if (wi::gt_p (shift, wi::uhwi (TYPE_PRECISION (type),
+                                    TYPE_PRECISION (op2.type ()))))
+       return false;
       if (shift == 0)
        {
          r = lhs;

Reply via email to