编译器优化可能会导致整数溢出。可以吗？

Question

我有一个整数 x。为简单起见，假设 ints 占据范围 -2^31 到 2^31-1。我想计算2 * x-1。我允许 x 是任何值 0

一种解决方案是计算< code>2*(x-1) 1。比我想要的多了一个减法，但是这个不应该溢出来。但是，编译器会将其优化为< code>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

Answer 1

ISO C规则适用于您的源代码(总是适用，不管目标机器是什么)。而不是编译器选择生成的asm，尤其是对于有符号整数包装只起作用的目标。

“as-if”规则要求函数的asm实现对于抽象机没有遇到有符号整数溢出（或其他未定义的行为）的每个输入值产生与C抽象机相同的结果。asm如何产生这些结果并不重要，这就是“仿佛”规则的全部要点。在某些情况下，如您的情况，最有效的实现将对抽象机器无法包装的某些值进行包装和展开，反之亦然。

有符号整数溢出在 C 抽象机中为 UB 的一个影响是，它允许编译器优化 int 循环计数器以指示指针宽度，而不是每次通过循环或类似操作时都重做符号扩展。此外，编译器还可以推断值范围限制。但这与他们如何将逻辑实现到某些目标机器的asm中是完全分开的。UB并不意味着“需要失败”，实际上恰恰相反，除非你用-fsanitize=undefined编译。对于优化器来说，如果您用比ISO C实际给出的更多的保证来解释源代码，那么优化程序可以使asm与源代码不匹配（加上实现超出此范围的任何保证，例如如果您使用gcc -fwrapv。）

对于像< code>x/2这样的表达式，每个可能的< code>int x都有明确定义的行为。对于< code>2*x，编译器可以假设< code>x

2*（x-1） 1 表示合法值范围 x 与 2*x-1 的合法值范围相差 1。它们为每个x产生相同的结果，这是它们两个都明确定义的输入，因此如果编译器没有为两者提供相同的有效asm，那么它将做得很糟糕。

延伸阅读:

• 是否有一些有意义的统计数据来证明保持有符号整数算术溢出未定义是合理的？re：它允许的一些有用的循环优化。
• http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
• 未定义的行为是否适用于ASM代码？（否）
• 内联x86程序集中的整数溢出是未定义的吗？

整个情况基本上是一团糟，C语言的设计者没有预料到当前优化编译器的复杂性。像Rust这样的语言更适合它：如果你想要包装，你可以（而且必须）告诉编译器关于它的每个操作，无论是有符号类型还是无符号类型。例如x.wrapping_add（1）。

Answer 2

仅仅因为有符号整数溢出在C语言级别没有很好的定义(直到C 20 ),并不意味着在汇编级别也是如此。由编译器来发出在目标CPU架构上定义良好的汇编代码。

我很确定本世纪制造的每个CPU都使用了2的补码有符号整数，溢出是为这些整数很好地定义的。这意味着简单地计算2*x，让结果溢出，然后减去1，让结果下限溢位是没有问题的。

存在许多这样的C语言级规则来掩盖不同的CPU架构。在这种情况下，有符号整数溢出未定义，以便针对使用一个人的赞美或有符号整数的符号/大小表示的CPU的编译器不会被迫添加额外的html" target="_blank">指令来符合两个赞美的溢出行为。

但是，不要假设您可以使用在目标CPU上定义良好但在C中未定义的构造，并得到您期望的答案。C编译器假定在执行优化时不会发生未定义的行为，因此如果代码不是定义良好的C，它们可以并且将发出与您期望的不同的代码。

Answer 3

正如Miles所暗示的：C代码文本受C语言规则的约束（integer overflow=bad），但编译器仅受cpu规则的约束（overflow=ok）。允许进行代码不允许的优化。

但不要以此为借口偷懒。如果你写了未定义的行为，编译器会认为这是一个提示，并进行其他优化，导致你的程序做了错误的事情。