C++左移操作使用字面量与变量时结果不同的问题排查

环境与代码 #

在Debian 12系统中，使用GCC 12.2.0编译器并以-std=c++2a选项编译以下C++代码：

#include <iostream>

int main()
{
 uint32_t b = 64;
 std::cout << std::hex << (0xFFFFFFFFFFFFFFFFULL << b) << "<< 64" << "\n";
 std::cout << std::hex << (0xFFFFFFFFFFFFFFFFULL << 64) << "<< 64" << "\n";
 std::cout << std::hex << (0xFFFFFFFFFFFFFFFFULL << 65) << "<< 65" << "\n";
 return 0;
}

运行结果 #

ffffffffffffffff<< 64
0<< 64
0<< 65

用户疑问 #

期望左移64位时结果为0，但使用变量b和直接使用字面量64得到的结果不一致，已查阅C++移位未定义行为相关资料，仍不清楚问题所在。

原因分析 #

• 编译期常量移位的处理
  当移位操作的右操作数是编译期常量（比如字面量64）时，GCC会在编译阶段完成计算。对于unsigned long long（64位无符号整数，对应代码中的ULL后缀类型），C++20及以后标准明确规定：移位位数等于或超过类型位宽时，结果为0。因此0xFFFFFFFFFFFFFFFFULL << 64会被编译器直接优化为0。

• 运行时变量移位的行为
  当右操作数是运行时变量（比如uint32_t b = 64）时，编译器无法提前确定移位值，只能生成运行时执行的CPU移位指令。x86_64架构的64位移位指令（如shlq）会对移位位数取模，即实际生效的位数为b % 64。这里64 % 64 = 0，相当于左移0位，结果就是原数0xFFFFFFFFFFFFFFFFULL，也就是输出的ffffffffffffffff。

• 标准与硬件行为的差异
  C++20及以后标准对无符号整数的超宽移位行为做了明确规定（结果为0），但CPU硬件指令的行为可能和标准不完全一致。编译器对编译期常量会严格遵循标准计算，而运行时移位则直接调用硬件指令，这就导致了两种写法的结果差异。

内容的提问来源于stack exchange，提问作者Antony