Is right shift undefined behavior if the count is larger than the width of the type?

I just checked the C++ standard. It seems the following code should NOT be undefined behavior:

unsigned int val = 0x0FFFFFFF;
unsigned int res = val >> 34;  // res should be 0 by C++ standard,
                               // but GCC gives warning and res is 67108863

And from the standard:

The value of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a non-negative value, the value of the result is the integral part of the quotient of E1/2^E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined.

According to the standard, since 34 is NOT an negative number, the variable res will be 0.

GCC gives the following warning for the code snippet, and res is 67108863:

warning: right shift count >= width of type

I also checked the assembly code emitted by GCC. It just calls SHRL, and the Intel instruction document for SHRL, the res is not ZERO.

So does that mean GCC doesn't implement the standard behavior on Intel platform?

Solution 1:

The draft C++ standard in section 5.8 Shift operators in paragraph 1 says(emphasis mine):

The type of the result is that of the promoted left operand. The behavior is undefined if the right operand is negative, or greater than or equal to the length in bits of the promoted left operand.

So if unsigned int is 32 bits or less then this is undefined which is exactly the warning that gcc is giving you.

Solution 2:

To explain exactly what happens: The compiler will load 34 into a register, and then your constant in another register, and perform a right shift operation with those two registers. The x86 processor performs a "shiftcount % bits" on the shift value, meaning that you get a right-shift by 2.

And since 0x0FFFFFFF (268435455 decimal) divided by 4 = 67108863, that's the result you see.

If you had a different processor, for example a PowerPC (I think), it may well give you zero.