This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: Re: c/7284: incorrectly simplifies leftshift followed by signed power-of-2 division
- From: "Al Grant" <AlGrant at myrealbox dot com>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 15 Jul 2002 12:06:00 -0000
- Subject: Re: Re: c/7284: incorrectly simplifies leftshift followed by signed power-of-2 division
- Reply-to: "Al Grant" <AlGrant at myrealbox dot com>
The following reply was made to PR c/7284; it has been noted by GNATS.
From: "Al Grant" <AlGrant@myrealbox.com>
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.