c - 为什么/如何在此签名溢出测试中gcc编译未定义的行为，以便它可以在x86上运行但不能在ARM64上运行？

Question

我在自学csapp，在运行断言测试时遇到了一个奇怪的问题，得到了一个奇怪的结果。
我不知道如何开始这个问题，所以让我先得到代码（文件名在注释中可见）：

// File: 2.30.c
// Author: iBug

int tadd_ok(int x, int y) {
    if ((x ^ y) >> 31)
        return 1;  // A positive number and a negative integer always add without problem
    if (x < 0)
        return (x + y) < y;
    if (x > 0)
        return (x + y) > y;
    // x == 0
    return 1;
}

// File: 2.30-test.c
// Author: iBug

#include <assert.h>

int tadd_ok(int x, int y);

int main() {
    assert(sizeof(int) == 4);

    assert(tadd_ok(0x7FFFFFFF, 0x80000000) == 1);
    assert(tadd_ok(0x7FFFFFFF, 0x7FFFFFFF) == 0);
    assert(tadd_ok(0x80000000, 0x80000000) == 0);
    return 0;
}

和命令：

gcc -o test -O0 -g3 -Wall -std=c11 2.30.c 2.30-test.c
./test

（附带说明：命令行中没有任何 -O选项，但由于它默认为0级，显式添加 -O0不会有太大变化。）
上面两个命令在我的ubuntu vm（amd64，gcc 7.3.0）上运行得很好，但是其中一个断言在我的android手机（aarch64或armv8-a，gcc 8.2.0）上失败了。

2.30-test.c:13: main: assertion "tadd_ok(0x7FFFFFFF, 0x7FFFFFFF) == 0" failed

注意，传递的第一个断言，因此平台上的 int保证为4字节。
所以我在手机上发了一通短信想了解一下：

(gdb) l 2.30.c:1
1       // File: 2.30.c
2       // Author: iBug
3
4       int tadd_ok(int x, int y) {
5           if ((x ^ y) >> 31)
6               return 1;  // A positive number and a negative integer always add without problem
7           if (x < 0)
8               return (x + y) < y;
9           if (x > 0)
10              return (x + y) > y;
(gdb) b 2.30.c:10
Breakpoint 1 at 0x728: file 2.30.c, line 10.
(gdb) r
Starting program: /data/data/com.termux/files/home/CSAPP-2019/ch2/test
warning: Unable to determine the number of hardware watchpoints available.
warning: Unable to determine the number of hardware breakpoints available.

Breakpoint 1, tadd_ok (x=2147483647, y=2147483647)
    at 2.30.c:10
10              return (x + y) > y;
(gdb) p x
$1 = 2147483647
(gdb) p y
$2 = 2147483647
(gdb) p (x + y) > y
$3 = 0
(gdb) c
Continuing.
2.30-test.c:13: main: assertion "tadd_ok(0x7FFFFFFF, 0x7FFFFFFF) == 0" failed

Program received signal SIGABRT, Aborted.
0x0000007fb7ca5928 in abort ()
   from /system/lib64/libc.so
(gdb) d 1
(gdb) p tadd_ok(0x7FFFFFFF, 0x7FFFFFFF)
$4 = 1
(gdb)

正如您在gdb输出中看到的，结果非常不一致，因为已到达 gdb上的 return语句，并且返回值应该是0，但是函数仍然返回1，从而使断言失败。
请告诉我这里有什么问题。
请尊重我所介绍的。仅仅说它是ub而不涉及平台，特别是gdb输出，是没有任何帮助的。

Answer 1

有符号溢出是iso c中未定义的行为。您不能可靠地导致它，然后检查它是否发生。
在表达式(x + y) > y;中，允许编译器假定x+y不会溢出（因为这将是ub）。因此，它优化到检查x > 0。（是的，实际上，gcc甚至在-O0时也会这样做）。
这种优化在GCC8中是新的。在x86和aarch64上也是一样的；在aarch64和x86上必须使用不同的gcc版本。（即使在-O3、gcc7.x及更早版本（有意？）错过这个优化。Clang7.0也不会这么做。他们实际上做了一个32位的加法和比较。它们还没有优化tadd_ok以return 1或add并检查溢出标志（arm上的V和x86上的OF）。clang优化的asm是>>31或一个xor操作的有趣组合，但是-fwrapv实际上改变了asm，所以它可能不会执行完全溢出检查。）
你可以说gcc8“破坏”了你的代码，但实际上它已经被破坏了，因为它是合法的/可移植的iso c。
为了看得更清楚，让我们把这个表达式分离成一个函数。gcc -O0无论如何都会单独编译每个语句，因此仅在x<0时运行的信息不会影响-O0函数中此语句的tadd_ok代码生成。

// compiles to add and checking the carry flag, or equivalent
int unsigned_overflow_test(unsigned x, unsigned y) {
    return (x+y) >= y;    // unsigned overflow is well-defined as wrapping.
}

// doesn't work because of UB.
int signed_overflow_expression(int x, int y) {
    return (x+y) > y;
}

On the Godbolt compiler explorer with AArch64 GCC8.2 -O0 -fverbose-asm

signed_overflow_expression:
    sub     sp, sp, #16       //,,      // make a stack fram
    str     w0, [sp, 12]      // x, x   // spill the args
    str     w1, [sp, 8]       // y, y
   // end of prologue

   // instructions that implement return (x+y) > y; as return  x > 0
    ldr     w0, [sp, 12]      // tmp94, x
    cmp     w0, 0     // tmp94,
    cset    w0, gt  // tmp95,                  // w0 = (x>0) ? 1 : 0
    and     w0, w0, 255       // _1, tmp93     // redundant

  // epilogue
    add     sp, sp, 16        //,,
    ret     

gcc -ftree-dump-original或 -optimized甚至可以通过这种优化（从godbolt链接）将其gimple变回类似于c的代码：

;; Function signed_overflow_expression (null)
;; enabled by -tree-original

{
  return x > 0;
}

不幸的是，即使使用 -Wall -Wextra -Wpedantic，也没有关于比较的警告。事实并非如此；它仍然依赖于 x。
优化后的asm无疑是 cmp w0, 0/ cset w0, gt/ ret。带 0xff的和是多余的。 cset is an alias of csinc，使用零寄存器作为两个源。所以它将产生0/1。对于其他寄存器， csinc的一般情况是任意2个寄存器的条件选择和增量。
无论如何， cset是aarch64的x86 setcc等价物，用于将寄存器中的标志条件转换为 bool。
如果你想让你的代码像写的那样工作，你就需要 compile with -fwrapv使它在使gcc实现的c变体中有定义良好的行为。默认值为 -fwrapv，与isoc标准类似。
如果要在现代C语言中检查有符号溢出，则需要编写检测溢出而不实际导致溢出的检查。这是编译器编写者和（某些）开发人员之间比较困难、恼人和争论的焦点。他们认为，围绕未定义行为的语言规则并不是用来作为在为目标机器编译代码时“无端中断”代码的借口，因为在目标机器上编译代码在asm中是有意义的。但现代编译器大多只实现iso c（具有一些扩展和额外定义的行为），即使是在为目标体系结构（如x86和arm）编译时，有符号整数没有填充（因此包装得很好），也不会捕获溢出。
所以你可以说在那场战争中“开火了”，GCC8.x中的更改实际上是“破坏”了这样的不安全代码。：p页
参见 Detecting signed overflow in C/C++和 How to check for signed integer overflow in C without undefined behaviour?
由于有符号和无符号加法在2的补码中是相同的二进制操作，您可以将加法转换为 -fstrict-overflow，然后将有符号比较转换回。这将使函数的版本在“正常”实现中是安全的：2的补码，在 unsigned和 unsigned之间转换只是对相同位的重新解释。
这不可能有ub，它只是不能在补码或符号/幅度c实现上给出正确的答案。

return  (int)((unsigned)x + (unsigned)y) > y;

它编译（对于aarch64，使用gcc8.2-o3）到

    add     w0, w0, w1            // x+y
    cmp     w0, w1                // x+y  cmp  y
    cset    w0, gt
    ret

如果您将 int作为 int sum = x+y中的一个单独的c语句编写，那么在禁用优化的情况下，gcc将看不到这个ub。但作为同一表达式的一部分，即使是默认值为 return sum < y的 gcc也可以看到它。
编译时可见的ub是各种各样的坏东西。在这种情况下，只有特定范围的输入才会产生ub，所以编译器假定不会发生这种情况。如果在执行路径上看到无条件的ub，优化编译器可以假设路径永远不会发生。（在没有分支的函数中，它可以假设函数从未被调用，并将其编译为单个非法指令。）有关编译时可见ub的详细信息，请参见 Does the C++ standard allow for an uninitialized bool to crash a program?。
（ -O0并不意味着“没有优化”，它意味着除了已经需要通过gcc的内部表示转换到asm的任何目标平台之外，没有额外的优化。@Basile Starynkevitch在
Disable all optimization options in GCC
在禁用优化的情况下，其他一些编译器可能会“关闭大脑”，并做一些更接近于将c转换为asm的事情，但gcc不是这样的。例如，gcc仍然使用乘法逆来除以 -O0处的常数。（ Why does GCC use multiplication by a strange number in implementing integer division?）所有其他3个主要x86编译器（clang/icc/msvc）都使用 -O0。