From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20901 invoked by alias); 27 Jul 2010 23:09:30 -0000 Received: (qmail 20847 invoked by alias); 27 Jul 2010 23:09:13 -0000 Date: Tue, 27 Jul 2010 23:09:00 -0000 Message-ID: <20100727230913.20846.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/45034] [4.3/4.4/4.5/4.6 Regression] "safe" conversion from unsigned to signed char gives broken code In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "rakdver at kam dot mff dot cuni dot cz" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-07/txt/msg03018.txt.bz2 ------- 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