Arithmetic right shift gives bogus result?

Question

I must be absolutely crazy here, but gcc 4.7.3 on my machine is giving the most absurd result. Here is the exact code that I'm testing:

#include <iostream>

using namespace std;

int main(){
  unsigned int b = 100000;
  cout << (b>>b) << endl;
  b = b >> b;
  cout << b << endl;
  b >>= b;
  cout << b << endl;
  return 0;
}

Now, any number that's right shifted by itself should result in 0 (n/(2^n) == 0 with integer divide, n>1, and positive/unsigned), but somehow here is my output:

100000
100000
100000

Am I crazy? What could possibly be going on?

@ShafikYaghmour: That assumes the compiler even bothers putting in an instruction. It's well within its right to just reject this program. — MSalters
@MSalters indeed, we are getting into compiler/platform/version specific at this point but for current and recent versions this is the case and as I already stated it is undefined so you are clearly on your own, gcc only seems to produce a shr when using -O0. — Shafik Yaghmour
@ShafikYaghmour: Intel is just one of the many platforms supported by gcc, and they have different optimization stages. A common trick in optimization is to say "This value can only be between 0 and 31 because it's used in a shift, if I follow code path X to get here the value would not be between 0 and 31, so code path X is impossible and I don't even need to generate instructions for it". GCC famously does this for null pointer checks. — MSalters
@MSalters that makes sense, so this would effect warnings as well? — Shafik Yaghmour
A fun fact: though this is undefined behavior in C, it is defined behavior in C#, but the definition is somewhat bizarre. In C#, x>>y for 32 bit ints x and y is computed as x>>(y&0x1f) ! So (x >> 16) >> 16 is zero, but x >> 32 is x. — Eric Lippert

davmac davmac · Accepted Answer · 2013-10-28T13:51:40

In C++ as in C, shifts are limited to the size (in bits) of the value shifted. For instance, if unsigned int is 32 bits, then a shift of more than 31 is undefined.

In practice, a common result is that the 5 least-significant bits of the shift amount are used and the higher order bits are ignored; this is due to the compiler producing a machine instruction which does exactly that (eg SHR on x86).

In this case, the shift value is 100000 (decimal) which happens to be 11000011010100000 in binary - the lower 5 bits are zero. So, you're effectively getting a shift by 0. You shouldn't rely on this however; technically, what you're seeing is undefined behaviour.

References:

For C, N1570 section 6.5.7:

If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined.

For C++, N3690 section 5.8 "[expr.shift]":

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.

N1570 is a draft, nearly identical to the released ISO C11 standard; this clause has been pretty much the same since the 1989 ANSI C standard.

N3690 is a recent draft of the C++ standard; I'm not sure whether it's the best one to use, but again, this clause hasn't changed.

Arithmetic right shift gives bogus result?

2 Answers