Re: Fixing the wrapping issue

[Sebastian Pop <sebastian dot pop at cri dot ensmp dot fr>]

Daniel Berlin wrote:
> On Tue, 2005-08-16 at 02:29 +0200, Sebastian Pop wrote:
> > Daniel Berlin wrote:
> > > I think the base problem we have is related to this:
> > > 
> > >   /* If AT_STMT represents a cast operation, we may not be able to
> > >      take advantage of the undefinedness of signed type evolutions.
> > >      See PR 21959 for a test case.  Essentially, given a cast
> > >      operation
> > >                 unsigned char i;
> > >                 signed char i.0;
> > >                 ...
> > >                 i.0_6 = (signed char) i_2;
> > >                 if (i.0_6 < 0)
> > >                   ...
> > > 
> > >      where i_2 and i.0_6 have the scev {0, +, 1}, we would consider
> > >      i_2 to wrap around, but not i.0_6, because it is of a signed
> > >      type.  This causes VRP to erroneously fold the predicate above
> > >      because it thinks that i.0_6 cannot be negative.  */
> > > 
> > > i.0_6 *doesn't* wrap around (it can't, by definition, it's signed).  i_2
> > > does.
> > > 
> > 
> > Could somebody recall me what is the result of the following conversion:
> > 
> >   u = (unsigned char) 255;
> >   s = (signed char) u;
> > 
> > is the signed char conversion defined to be -1 or not defined in this case?
> 
> 6.3.1.3 Signed and unsigned integers
> 1 When a value with integer type is converted to another integer type
> other than _Bool,
> the value can be represented by the new type, it is unchanged.
> 2 Otherwise, if the new type is unsigned, the value is converted by
> repeatedly adding
> subtracting one more than the maximum value that can be represented in
> the new
> until the value is in the range of the new type.49)
> 3 Otherwise, the new type is signed and the value cannot be represented
> in it; either
> result is implementation-defined or an implementation-defined signal is
> raised.
> 
> 
> 
> The new type here is signed, so it falls into category 3.
> 

Okay, so the result is not defined unless using -fwrapv.

the possible ranges for the example are:
i_2 is unsigned, and thus it can go from [0, 255]
i.0_6 is a signed char, its range is [0, 127]
and this last deduction could be used to restrict the range of i_2 to [0, 127].

So why "if (i.0_6 < 0)" cannot be folded into "if (0)"?

This also seems to me like a wrong fix to PR 21959... or probably the
comments are misleading?