Result of shift when operand == type size
Kai Harrekilde-Petersen
kai.harrekilde-petersen@exbit.dk
Tue Apr 25 09:33:00 GMT 2000
Hi Horst,
Horst von Brand wrote:
>
> "Kai Harrekilde-Petersen" <kai.harrekilde-petersen@exbit.dk> said:
> > According to K&R (2ed), pg 206, the result of a shift,
> > is undefined "if right operand is negative, or greater than or
> > equal to the number of bits in the left expression's type"
> > (A7.8 Shift Operators).
>
> This is to allow just doing the shift; if the CPU gives garbage in these
> cases, garbage is handled to the user. This way the compiler doesn't have
> to go out of its way to check beforehand.
Point taken. Dang, I used mask macros pretty intensively in a MIPS disassembler
I wrote some years ago, without getting myself into this mess. Oh well.
> > GCC follows this a bit too faithfully, IMHO. Specifically,
> > ~(~0ULL<<64) != ~0ULL. This complicates writing bitmask macros.
>
> I'd assume your machine is doing this, not the compiler. Look at the
> assembly code generated.
After staring at the assembly code for five minutes (I'm not used to do
that :) I've come to the conclusion that, yes you are right. However, in
the MASKSZ(64) case, egcc emits:
.L3:
pushl $0
pushl $-1
pushl $.LC1
call printf
which is 0x00000000ffffffff. Given a free choice, I'd says that gcc
should have returned ~0ULL, not ((unsigned long long) ~0UL) since gcc
ought to be able to compute that with "infinite precision", but given
A7.8, anything goes...
Thanks for your comments,
Kai
--
Kai Harrekilde-Petersen
Exbit Technology A/S
More information about the Gcc-bugs
mailing list