Re: Fixing the wrapping issue

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

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?

I find the example hard to read.  I'll commit the following rewording
of the comment above, such that it renames these i and i.0 to make
the example simpler to read.

*** tree-ssa-loop-niter.c.~2.36.~	2005-08-14 22:38:03.000000000 +0200
--- tree-ssa-loop-niter.c	2005-08-16 02:19:02.000000000 +0200
***************
*** 1893,1909 ****
       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.  */
    if (at_stmt && TREE_CODE (at_stmt) == MODIFY_EXPR)
      {
        tree rhs = TREE_OPERAND (at_stmt, 1);
--- 1893,1909 ----
       take advantage of the undefinedness of signed type evolutions.
       See PR 21959 for a test case.  Essentially, given a cast
       operation
!      		unsigned char uc;
! 		signed char sc;
  		...
!      		sc = (signed char) uc;
! 		if (sc < 0)
  		  ...
  
!      where uc and sc have the scev {0, +, 1}, we would consider uc to
!      wrap around, but not sc, because it is of a signed type.  This
!      causes VRP to erroneously fold the predicate above because it
!      thinks that sc cannot be negative.  */
    if (at_stmt && TREE_CODE (at_stmt) == MODIFY_EXPR)
      {
        tree rhs = TREE_OPERAND (at_stmt, 1);