Strange bit shifting result with gcc - am I missing somethingobviou s?

[Boltar]

On 32 bit linux with gcc 4.2 I get unexpected results with this code:

main()
{
int bits = 32;
printf("%d\n",( int)1 << (int)32);
printf("%d\n",( int)1 << bits);
}
The first printf gives a result of 0, the second gives 1. I checked
with sizeof() and ints are definately 32 bits in size.

I'm sure I'm missing something obvious but can someone tell me what?

Thanks

B2003

[jacob navia]

Boltar wrote:

On 32 bit linux with gcc 4.2 I get unexpected results with this code:

main()
{
int bits = 32;
printf("%d\n",( int)1 << (int)32);
printf("%d\n",( int)1 << bits);
}
The first printf gives a result of 0, the second gives 1. I checked
with sizeof() and ints are definately 32 bits in size.

I'm sure I'm missing something obvious but can someone tell me what?

Thanks

B2003

When I compile tyour code with lcc-win I get:

Warning tshift.c: 2 no type specified. Defaulting to int

The prototype for main is:
int main(void)

Warning tshift.c: 5 missing prototype for printf

You did not include <stdio.h>

Warning tshift.c: 5 shift by 32 is undefined

The number of bits shifted is greater than sizeof(int)*CHA R_BIT
This is undefined!

The result of running the program is:

16777216
1

If I turn optimizations ON I get:
16777216
1024

The result of shifting more than sizeof(int)*CHA R_BIT positions
is NOT defined by the language. It is an illegal expression.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Eric Sosman]

Boltar wrote:

On 30 Mar, 21:37, jacob navia <ja...@nospam.c omwrote:

>The result of shifting more than sizeof(int)*CHA R_BIT positions
is NOT defined by the language. It is an illegal expression.

It isn't? Thats bloody annoying since that means i'll have to do a
specific check for the bit shift count being than the size of the
type being shifted.

Actually, you need to check for >=, not just >. And
with signed integers, you need to be sure the value being
shifted is non-negative and small enough that no 1's are
propagated into the sign position.

--
Eric Sosman
es*****@ieee-dot-org.invalid

[Bartc]

"jacob navia" <ja***@nospam.c omwrote in message
news:fs******** **@aioe.org...

Boltar wrote:

>On 32 bit linux with gcc 4.2 I get unexpected results with this code:

main()
{
int bits = 32;
printf("%d\n",( int)1 << (int)32);
printf("%d\n",( int)1 << bits);
}
The first printf gives a result of 0, the second gives 1. I checked
with sizeof() and ints are definately 32 bits in size.

I'm sure I'm missing something obvious but can someone tell me what?

When I compile tyour code with lcc-win I get:

Warning tshift.c: 5 shift by 32 is undefined

The number of bits shifted is greater than sizeof(int)*CHA R_BIT
This is undefined!

OK, but the following code from lccwin does not appear to set up the shift
count in cl register. So you don't even attempt to shift by 32, but by an
unknown value in cl (presumably 24)?

; 6 printf("%d\n",( int)1 << (int)32);
.line 6
movl $1,%edi
movl $32,%esi
sall %cl,%edi

On the x86 at least, shifting a 32-bit register left by 32 is anyway a
no-operation (the register is unchanged).

So the OP should not rely on 32+ bit left-shifts working as he expects.

--
Bart

[jacob navia]

Bartc wrote:

OK, but the following code from lccwin does not appear to set up the shift
count in cl register. So you don't even attempt to shift by 32, but by an
unknown value in cl (presumably 24)?

; 6 printf("%d\n",( int)1 << (int)32);
.line 6
movl $1,%edi
movl $32,%esi
sall %cl,%edi

On the x86 at least, shifting a 32-bit register left by 32 is anyway a
no-operation (the register is unchanged).

So the OP should not rely on 32+ bit left-shifts working as he expects.

Surely not. Things go as follows:

lcc-win discovers that we have a shift operation with
two immediate constants. This should be done at
compile time to make the generated program more efficient.

Then it discovers that one of the constants is too big
and generates a warning. Apparently, when making this
optimizations it doesn't set cl.

If you change the program to
5 printf("%d\n",( int)1 << (int)31);
.line 5
pushl $-2147483648 // Shift done at compile time
pushl $_$2
call _printf
addl $8,%esp

You see?

Now, it can be argued that this is a bug. True.

I have changed this now so that it will do the shift at compile time,
returning whatever the result is at compile time (1) anyway.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[lawrence.jones]

Boltar <bo********@yah oo.co.ukwrote:

On 32 bit linux with gcc 4.2 I get unexpected results with this code:

main()
{
int bits = 32;
printf("%d\n",( int)1 << (int)32);
printf("%d\n",( int)1 << bits);
}
The first printf gives a result of 0, the second gives 1. I checked
with sizeof() and ints are definately 32 bits in size.

I'm sure I'm missing something obvious but can someone tell me what?

That the shift count must be *less than* the number of bits in the
operand or you get undefined behavior.

-Larry Jones

Please tell me I'm adopted. -- Calvin

[lawrence.jones]

Boltar <bo********@yah oo.co.ukwrote:

>
It isn't? Thats bloody annoying since that means i'll have to do a
specific check for the bit shift count being than the size of the
type being shifted.

The theory is it's better to have to have an explicit check for the
relatively small amount of code that needs it than to have the compiler
always generate for the vast majority of code that doesn't need it.

-Larry Jones

OK, what's the NEXT amendment say? I know it's in here someplace. -- Calvin

[lawrence.jones]

Bartc <[e-mail] rote:

>
On the x86 at least, shifting a 32-bit register left by 32 is anyway a
no-operation (the register is unchanged).

On the contrary, different processors in the x86 family behave
differently. Some only look at the bottom 5 bits of the count (so a
shift count of 32 is interpreted as 0 and 33 as 1) but others look at
the entire value (so a shift count of 32 or greater zeros the register).

-Larry Jones

You're just trying to get RID of me, aren't you? -- Calvin

[Gordon Burditt]

>OK, but the following code from lccwin does not appear to set up the shift

>count in cl register. So you don't even attempt to shift by 32, but by an
unknown value in cl (presumably 24)?

; 6 printf("%d\n",( int)1 << (int)32);
.line 6
movl $1,%edi
movl $32,%esi
sall %cl,%edi

On the x86 at least, shifting a 32-bit register left by 32 is anyway a
no-operation (the register is unchanged).

So the OP should not rely on 32+ bit left-shifts working as he expects.

Surely not. Things go as follows:

lcc-win discovers that we have a shift operation with
two immediate constants. This should be done at
compile time to make the generated program more efficient.

Then it discovers that one of the constants is too big
and generates a warning. Apparently, when making this
optimization s it doesn't set cl.

This is not a bug. 1 << 32 invokes the wrath of undefined behavior.
Since no possible answers are wrong, you might as well get one
quickly, even if it's random crap.

>If you change the program to
5 printf("%d\n",( int)1 << (int)31);
.line 5
pushl $-2147483648 // Shift done at compile time
pushl $_$2
call _printf
addl $8,%esp

You see?

Now, it can be argued that this is a bug. True.

I'll argue that the wording of the error message is a
quality-of-implementation issue.

>I have changed this now so that it will do the shift at compile time,
returning whatever the result is at compile time (1) anyway.

[=?ISO-8859-1?Q?Tom=E1s_=D3_h=C9ilidhe?=]

jacob navia:

The number of bits shifted is greater than sizeof(int)*CHA R_BIT
This is undefined!

Don't forget about systems that have padding bits within their integer
types. On such systems, sizeof(some int type)*CHAR_BIT will yield a
value which is larger than the amount of value representationa l bits
in that type.