Why is unsigned left bit shift overflow different between runtime and compile time?

Question

I have the following code in C++

#include <iostream>
using namespace std;
int main(){
    unsigned long long a;
    cin>>a;
    cout<< (1ull<<64ull) << ' ' << (1ull<<a) << endl;
}

now inputting 64, the output is

0 1

In short, the compiler seems to use a circular shift at runtime. But from my reading of the relevant cppreference page, I think it's supposed to be normal modular arithmetic, so the bit should just disappear as in the compile-time version. I tested this on GCC 11, GCC 12 and clang 14 so it's extra unlikely to be a compiler bug. So what am I missing here?

`1ull<<64ull` exhibits undefined behavior, and so does `1ull<= 64`. I'm assuming `unsigned long long` is 64 bits on your platform. "**[expr.shift]/1** The behavior is undefined if the right operand is negative, or greater than or equal to the width of the promoted left operand." — Igor Tandetnik, Jan 28 '23 at 17:02
It's undefined behavior. The x86 compilers all just generate [a `SHL reg, CL` instruction](https://c9x.me/x86/html/file_module_x86_id_285.html). On x86, the shift count is masked, which is why you're seeing the output that you are. You should not rely upon it; that's what undefined behavior means. — Cody Gray - on strike, Jan 28 '23 at 17:08

score 1 · Answer 1 · answered Jan 28 '23 at 17:06

from the quoted cppreference page

In any case, if the value of the right operand is negative or is greater or equal to the number of bits in the promoted left operand, the behavior is undefined.

since 64 is the number of bits in unsigned long long on my machine, this is undefined behavior

Why is unsigned left bit shift overflow different between runtime and compile time?

1 Answers1