Re: Result of shift when operand == type size

["Kai Harrekilde-Petersen" <kai dot harrekilde-petersen at exbit dot dk>]

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