From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2232 invoked by alias); 15 Jul 2002 12:06:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 2218 invoked by uid 71); 15 Jul 2002 12:06:00 -0000 Date: Mon, 15 Jul 2002 05:06:00 -0000 Message-ID: <20020715120600.2217.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: "Al Grant" Subject: Re: Re: c/7284: incorrectly simplifies leftshift followed by signed power-of-2 division Reply-To: "Al Grant" X-SW-Source: 2002-07/txt/msg00460.txt.bz2 List-Id: The following reply was made to PR c/7284; it has been noted by GNATS. From: "Al Grant" To: nathan@codesourcery.com Cc: nathan@cs.bris.ac.uk, falk.hueffner@student.uni-tuebingen.de, nathan@gcc.gnu.org, algrant@acm.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: Re: c/7284: incorrectly simplifies leftshift followed by signed power-of-2 division Date: Mon, 15 Jul 2002 11:44:05 +0000 >> But left-shift is an operation on the >>representation, i.e. the bit pat= tern. >The *implementation* of left-shift is an operation on representation. >The abstract left shift operation applies to values. It applies to bit patterns. =20 Going back to K&R2 A7.8, they say=20 "The value of E1 << E2 is E1 (interpreted as a bit pattern) left-shifted E2 bits; in the absence of overflow, this is equivalent to multiplication by 2**E2." Now if left-shift was an abstract operation, why=20 didn't they just say "The value of E1 << E2 is E1 multiplied by 2**E2" Do you think K&R intended signed left-shift to result in undefined behavior? I rather think they expected it to do some well-defined operation on the machine representation, with tr= uncation implicit, but not one that could be standardised. >C++ says it that the bit pattern is left shifted and vacated bit positions >are zero filled. That we agree on. What we disagree is what happens to=20 >bits 'falling off the top' (be they zero or one). >I contend that if the >exact result (which will require 32+c bits to represent), is not >representable in 32 bits, then the behaviour is undefined (as [5]/5 >says). You contend that the result is reduced modulo 2^32. But then >why does C++ then go on to say 'if E1 is unsigned type ...' to specify >such a modulo reduction for unsigned types? I never said they should be reduced modulo 2**32. My claim all along has been that this is a function on representations and that some bits are implicitly discarded because that's what a bitwise shift does. It may be implementation-defined (as Falk Hueffner points out, this = is clarified by the=20 response to DR #081) but you have got to define it. What _is_ your impleme= ntation definition of the behavior on signed left shift? The definition for unsigned types in terms of a multiplication merely states an equivalence between an operation on the representation and an operation on the integers, which cannot be directly stated for the signed left shift because of the various different signed representations in existence. >> Representability is a property of the integers as numbers. >Representability is a property of representation formats. A given representation defines a boolean function on integers, namely whether they are representable or not. The point is that an operation on representations always has a representabl= e result.