Fixing the wrapping issue

[Daniel Berlin]

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.