From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13765 invoked by alias); 13 Jul 2005 18:10:48 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 13691 invoked by uid 22791); 13 Jul 2005 18:10:37 -0000 Received: from mr1.netezza.com (HELO mail2.netezza.com) (12.148.248.137) by sourceware.org (qpsmtpd/0.30-dev) with SMTP; Wed, 13 Jul 2005 18:10:37 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Strange shifting behaviour Date: Wed, 13 Jul 2005 18:10:00 -0000 Message-ID: From: "John Yates" To: "Eljay Love-Jensen" , "Ulf Magnusson" , X-SW-Source: 2005-07/txt/msg00132.txt.bz2 Eljay, Though I agree with your point about the standards and undefined behavior, I do believe that Ulf has identified a quality of implementation issue. Would you not agree that compile-time expression evaluation should mimic run-time as much as possible? Or to put it another way, the more often compile-time and run-time evaluated results diverge, the lower the subject quality of the compiler. If the shift operator at run-time examines only the lower order 5 bits of the shift count (as Ulf's x86 does) then a "high-quality" compile-time expression evaluator ought to do the same. /john -----Original Message----- From: Eljay Love-Jensen [mailto:eljay@adobe.com] Sent: Tuesday, July 12, 2005 6:46 PM To: Ulf Magnusson; gcc-help@gcc.gnu.org Subject: Re: Strange shifting behaviour Hi Ulf, >When shifting an int by its size in bits... That is undefined behavior (implementation dependent), as per C and C++ sta= ndards. Ever since C was first taking it's first baby steps. By "undefined behavior", that means any given particular implementation can: + not do anything + do what you expect + SEGV + format your hard drive --Eljay