为何"left shift count >= width of type"警告触发时机晚于预期？

背景说明 #

我使用64位（AMD64）小端系统，编译代码的命令为g++ -std=gnu++23 -O3 -Wall，以下代码片段呈现了一些看似反常的行为："left shift count >= width of type"警告的触发时机晚于预期，且似乎未按预期完成完整的整数提升。

#include <cstdint>
#include <iostream>

int main()
{
  // 当然，任意值都会引发这种令人困惑的行为
  uint8_t a = 5;
  a <<= 7;
  // 输出128，符合预期
  std::cout << static_cast<int>(a) << '\n';

  uint8_t b = 5;
  b <<= 8;
  // 输出0，符合预期，尽管有点可疑（8等于类型宽度，对吗？）
  std::cout << static_cast<int>(b) << '\n';

  uint8_t c = 5;
  c <<= 16;
  // 输出0，符合预期，假设已提升为更大的无符号整数类型
  std::cout << static_cast<int>(c) << '\n';

  uint8_t d = 5;
  d <<= 31;
  // 输出0，符合预期，假设已提升为更大的无符号整数类型
  std::cout << static_cast<int>(d) << '\n';

  uint8_t e = 5;
  e <<= 64;
  /*
    触发警告，这相当容易理解
    （我猜编译器未识别__uint128_t？）
  */
  // 仍输出0，但我认为这属于未定义行为
  std::cout << static_cast<int>(e) << '\n';

  uint8_t f = 5;
  f <<= 32;
  /*
    不知为何触发警告
    （难道不该提升为uint64_t吗？）
  */
  // 仍输出0，但我认为这属于未定义行为
  std::cout << static_cast<int>(f) << '\n';
}

问题 #

这究竟是怎么回事？

解答 #

核心原因是对C++的整数提升规则理解有误，以下是逐条拆解：

1. 整数提升的目标类型是int，不是uint64_t
   对于uint8_t这类窄无符号整数类型，只要它的所有取值都能被int容纳（uint8_t最大值255，远小于32位int的上限），在进行移位等操作前会先被提升为int，而非直接跳到64位无符号类型。这是C++标准明确规定的整数提升逻辑。

2. 逐个分析代码案例

   • a <<=7：a提升为32位int后左移7位，结果为5*2^7=128，赋值回uint8_t后保留低8位，输出128，符合预期。
   • b <<=8：b提升为32位int后左移8位，移位位数8远小于int的宽度32，操作合法。计算结果为5*2^8=1280，赋值回uint8_t时截断低8位（1280的低8位是0），所以输出0。编译器无警告是因为移位位数未超过提升后类型的宽度。
   • c <<=16、d <<=31：同样先提升为32位int，16和31都小于32，操作合法。移位后结果的低8位均为0，赋值回uint8_t后输出0，编译器不会触发警告。
   • e <<=64：e提升为32位int后，移位位数64远大于int的宽度32，违反C++标准（移位位数必须小于操作数的位数），因此触发警告。这属于未定义行为，编译器输出0只是其中一种可能的处理结果。编译器不会自动使用__uint128_t，因为整数提升的目标类型不会跳级到128位。
   • f <<=32：f提升为32位int后，移位位数32等于int的宽度，同样违反标准，触发警告。属于未定义行为，输出0是编译器的一种处理方式。

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