编译器优化或引发整数溢出？改写表达式仍被优化是否存在问题

问题背景 #

定义int x，假设int的取值范围为$-2^{31}$到$2{31}-1$，需要计算表达式2*x-1，且x的合法取值范围是$0 ≤ x ≤ 2^{{30}$。当`x`取$2}{30}$时，2*x的结果为$2^{31}$，超出int的上限，会触发整数溢出。

为避免溢出，改用表达式2*(x-1)+1——该表达式在合法x范围内无溢出，但编译器会将其优化为与2*x-1完全相同的汇编代码：

2*x-1编译后的汇编： #

func(int):                               # @func(int)
        lea     eax, [rdi + rdi]
        dec     eax
        ret

2*(x-1)+1编译后的汇编： #

func(int):                               # @func(int)
        lea     eax, [rdi + rdi]
        dec     eax
        ret

现需明确：这两种写法对源代码和可执行文件是否存在问题？

问题解答 #

1. 源代码层面 #

• 2*x-1存在潜在风险：在C/C++标准中，有符号整数溢出属于未定义行为。即使当前编译器能生成正确代码，语言标准并未对溢出后的行为做任何保证——未来编译器版本、优化等级变化时，可能生成不符合预期的代码，甚至引发其他逻辑错误。
• 2*(x-1)+1是安全合规的：在x的合法范围内（$0 ≤ x ≤ 2^{{30}$），`x-1`的范围是$-1$到$2}{30}-1$，2*(x-1)的范围是$-2$到$2^{{31}-2$，加1后结果范围为$-1$到$2}{31}-1$，完全落在int的取值范围内，无溢出风险，属于标准明确规定的、行为确定的写法。哪怕编译器将其优化为与2*x-1相同的汇编，也是在保证行为一致的前提下进行的优化，源代码本身的合规性不受影响。

2. 可执行文件层面 #

从给出的汇编代码来看，两个表达式最终生成的机器码完全一致，执行逻辑为：先将输入值乘2，再减1。
由于数学上2*x-1与2*(x-1)+1是恒等变换，即使硬件执行2*x时发生溢出（按补码规则循环），最终减1后的结果也与先计算x-1再乘2加1的结果完全相同。因此，可执行文件在合法x范围内的行为是正确的，不会出现计算错误。

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