Clang与GCC 12及以上版本整数比较行为差异的原因咨询
嗨，这个问题挺有意思的，我来帮你拆解一下背后的逻辑~
首先咱们先抓住代码里的核心矛盾点：你把0x80000000U赋值给了int32_t类型的x，但这个值是231，而`int32_t`（32位有符号整数）的范围是-231到2^31-1，所以这个值其实超出了int32_t能表示的正范围。根据C++标准，用超出有符号类型范围的值初始化该类型变量时，行为是实现定义的——简单说就是编译器可以自己决定怎么处理这个值。
老版本GCC和Clang的处理方式
这些编译器会直接把0x80000000U转成int32_t能表示的最小值：-2^31（也就是-2147483648）。
接下来对这个值取负：数学上-(-231)是231，但这个值同样超出了int32_t的范围，属于有符号整数溢出。在老版本里，编译器默认按照补码回绕的规则处理——也就是溢出后又绕回-2^31，所以x和-x在内存里的二进制完全一样，比较自然相等，输出"equal"。
GCC 12+行为变化的核心原因
GCC 12之后，团队对C++标准里“有符号整数溢出属于未定义行为”这一条做了更严格的优化。什么意思呢？标准允许编译器假设有符号整数永远不会溢出，所以优化器会基于这个假设来重构代码——毕竟如果溢出是未定义的，编译器就不需要考虑这种极端情况，能生成更高效的代码。
对于x = -2^31这种极端情况，优化器会认为“对最小有符号整数取负会导致溢出，而这种情况是未定义的，所以我们可以用更高效的方式处理表达式”——具体来说，它会把x和-x都提升到更大的整数类型（比如64位的long long）来进行计算：
- 提升后的
x是-2^31（64位能轻松表示） - 提升后的
-x是2^31（同样能被64位表示）
这时候一个是负数一个是正数，自然不相等，所以输出"NOT equal"。
为什么强制转成int32_t(-x)也没用？
因为在GCC 12+的优化逻辑里，-x的计算已经被提前提升到更大类型了，你再把它转成int32_t，本质上是把2^31这个超出范围的值转成int32_t，而这又是一个实现定义的行为。GCC 12+在这里的处理是，即使你加了强制转换，优化器依然会基于“溢出是未定义”的假设，认为这个转换后的结果和原x不相等——甚至可能直接把整个比较表达式当成永远为假，因为它觉得这种溢出情况“不应该存在”。
如果想让GCC 12+回到原来的行为，可以给编译器加上-fwrapv编译选项，这个选项会强制编译器把有符号整数溢出处理成补码回绕，这样输出就会和老版本GCC、Clang一致了。
内容来源于stack exchange
