From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14309 invoked by alias); 29 Nov 2004 17:12:18 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 14281 invoked from network); 29 Nov 2004 17:12:13 -0000 Received: from unknown (HELO mta05-winn.mailhost.ntl.com) (212.250.162.8) by sourceware.org with SMTP; 29 Nov 2004 17:12:13 -0000 Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20041129171213.LMRZ540.mta05-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com> for ; Mon, 29 Nov 2004 17:12:13 +0000 Received: from cuddles.cambridge.redhat.com ([82.16.12.40]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20041129171212.FYRL1092.aamta05-winn.mailhost.ntl.com@cuddles.cambridge.redhat.com> for ; Mon, 29 Nov 2004 17:12:12 +0000 Received: from redhat.com (localhost.localdomain [127.0.0.1]) by cuddles.cambridge.redhat.com (8.12.8/8.12.8) with ESMTP id iATHAnnq010583; Mon, 29 Nov 2004 17:10:59 GMT Received: (from aph@localhost) by redhat.com (8.12.8/8.12.8/Submit) id iATHAmow010577; Mon, 29 Nov 2004 17:10:48 GMT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16811.22552.200258.472826@cuddles.cambridge.redhat.com> Date: Mon, 29 Nov 2004 17:26:00 -0000 From: Andrew Haley To: "Dave Korn" Cc: "'Dale Johannesen'" , , "'Nathan Sidwell'" Subject: RE: warning: right shift count >= width of type In-Reply-To: References: <13C7A994-4224-11D9-B898-000A95D7D16C@apple.com> X-SW-Source: 2004-11/txt/msg01135.txt.bz2 Dave Korn writes: > > -----Original Message----- > > From: Dale Johannesen > > Sent: 29 November 2004 16:31 > > > On Nov 29, 2004, at 8:18 AM, Dave Korn wrote: > > > Afternoon all. Here's something that's piqued my curiosity; it's > > > probably > > > owing to some language-lawyerly issue, but it isn't obvious to me. > > > This is > > > on gcc-3.3.3, (cygwin variant, but that's probably not relevant): > > > > > > -------------------------------------------------- > > > dk@mace /test/shift-test> cat foo.c > > > > > > unsigned int bar (unsigned int baz) > > > { > > > unsigned int quux; > > > > > > quux = baz >> 32; > > > return quux; > > > } > > > Why isn't the shift operation optimised away and replaced with > > > const_int > > > 0? > > > > Because that's not what it means. Shifts by >= word size are > > undefined > > behavior > > and will give different results depending on optimization > > level and on > > whether > > the shift count is constant or variable. Don't do that. (If > > you think > > it ought to be 0, > > reflect that most popular CPUs have only 5 bit shift counts, and > > consider what the > > code for x >> y would have to look like.) > > > Absolutely so; my curiosity was piqued when I noticed that my > cross-compiler was generating illegal assembler code with an out-of-range > operand value that the assembler couldn't fit into the relevant opcode > bitfield. > > So my question is really "Given that it's undefined, which means that > whatever the compiler does is correct, and given that there's already code > in there to detect the situation and issue a warning, which probably means > that it would be very easy at such a point to replace the offending RTL with > (const_int 0), is there any specific reason why not to?" I think the idea is that a << n /* n == 32 */ and a << 32 should do the same thing. This seems IMO more helpful than optimizing away the shift. > I imagine that this is one of those areas where "undefined > behaviour" is the standard's way of saying "Well, some compilers in > the past got it right and some got it wrong and since the standard > is largely about codifying the de-facto behaviour of existing C > compilers we'll leave this one alone", No, not at all. The x86 processors interpret this as a << (n % 32) > but it's surely only an issue of bugward-compatibility: > mathematically, there's really no problem with right-shifting more > than the width of the integer, all that happens is that _all_ the > bits drop out the right-hand side and you're left with nothing. That's not what all hardware actually does with shift instructions. > ISTM reasonable that the result of a right-shift by 32 bits could > be assumed to be the same thing you get if you right-shift by 1 bit > 32 times.... The chip designers don't agree. Andrew.