From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25811 invoked by alias); 27 Jul 2010 22:43:26 -0000 Received: (qmail 25553 invoked by alias); 27 Jul 2010 22:42:51 -0000 Date: Tue, 27 Jul 2010 22:43:00 -0000 Message-ID: <20100727224251.25552.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: "joseph at codesourcery dot com" 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/msg03017.txt.bz2 ------- Comment #9 from joseph at codesourcery dot com 2010-07-27 22:42 ------- Subject: Re: [4.3/4.4/4.5/4.6 Regression] "safe" conversion from unsigned to signed char gives broken code On Tue, 27 Jul 2010, mikpe at it dot uu dot se wrote: > Personally I think GCC should treat source-level casts as wrapping, regardless > of -fstrict-overflow and -fno-wrapv. Perhaps it intends to, and we're just > seeing the effects of bugs. This implementation-defined behavior is already documented in implement-c.texi: @item @cite{The result of, or the signal raised by, converting an integer to a signed integer type when the value cannot be represented in an object of that type (C90 6.2.1.2, C99 6.3.1.3).} For conversion to a type of width @math{N}, the value is reduced modulo @math{2^N} to be within range of the type; no signal is raised. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45034