[Bug tree-optimization/45034] [4.3/4.4/4.5/4.6 Regression] "safe" conversion from unsigned to signed char gives broken code

["rakdver at kam dot mff dot cuni dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #10 from rakdver at kam dot mff dot cuni dot cz  2010-07-27 23:09 -------
Subject: Re:  [4.3/4.4/4.5/4.6 Regression]
        "safe" conversion from unsigned to signed char gives broken code

> >   ux = (unsigned char) x;
> >   uy = (unsigned char) -(signed char) ux;
> >   ...
> > }
> > 
> > That is, the negation of unsigned char value is implemented by casting it to
> > signed char, which introduces signed overflow if the value of x is -128.  As
> > far as I understand the C standard, this seems incorrect.
> 
> It depends on how GCC interprets that cast and negation:
> - if the cast has C semantics, then (signed char)ux causes overflow
> - if the cast wraps, then it is fine and yields (signed char)-128
> - if the negation has C semantics, then (signed char)-128 is widened to int and
> then negated to 128
> - if the negation maps signed char to signed char, then it causes overflow
> 
> IMO, a serious problem with the C standard is that
> 
>     signed char x = -1;
>     signed char y = (signed char)(unsigned char)x;
> 
> triggers signed overflow causing undefined behaviour.

no, it does not.  The semantics of the cast in this case is not undefined, it
is implementation-defined.  GCC defines it in the natural way (and induction
variable analysis takes that into account).  The problem is with the negation,
which causes overflow.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034