37

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?

Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
ZijingWu
  • 3,350
  • 3
  • 25
  • 40

2 Answers2

47

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.

Shafik Yaghmour
  • 154,301
  • 39
  • 440
  • 740
  • 8
    @Zaibis: Yes, GCC is able to compile C++. It is a common misconception that GCC is (only) a C compiler, or that G++ is a different compiler. – Dietrich Epp Sep 20 '13 at 16:47
  • 1
    @Zaibis: GCC is a toolchain; it has compilers (and linkers and lots of other things) for both C and C++. – Nawaz Sep 21 '13 at 10:08
20

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.

Mats Petersson
  • 126,704
  • 14
  • 140
  • 227
  • Correct me if I'm wrong, but I was doing the last days a lot with working on PPC and shifting, and gcc wasn't able to represent on PPC32 a 32bit shift of an integer. So are you sure about your statement refering to PPC? (I did work with C source but if the CPU arch isn't able to do so, the language shouldn't be relevant, shoudl it?) – dhein Sep 20 '13 at 16:22
  • 2
    @Zaibis GCC is a portable compiler, and there is no reason to disable the code inside GCC that warns for shifts by a number too large when it is emitting code for a PowerPC. But I can assure you that the PowerPC processor does have the couple of additional transistors that allow the assembly instruction for right-shift to produce the expected result when shifting by 34. – Pascal Cuoq Sep 20 '13 at 22:04
  • @dhein: ARM might be a better example, then. It does saturate shift counts, i.e. `lsr r0, r0, r1` will shift out all the bits if `r1` is 32 or higher. ARM can also encode immediate shifts with a count greater than 31, for example `lsr r0, r0, #32` does assemble. (All mainstream 32-bit ISAs have immediate shifts; the compiler won't actually load `34` into a register unless you do `int count = 34;` / `val <<= count;` in a debug build.) – Peter Cordes Apr 28 '22 at 02:47