如何防止gcc优化器产生错误的位操作？

Question

考虑以下程序。

#include <stdio.h>

int negative(int A) {
    return (A & 0x80000000) != 0;
}
int divide(int A, int B) {
    printf("A = %d\n", A);
    printf("negative(A) = %d\n", negative(A));
    if (negative(A)) {
        A = ~A + 1;
        printf("A = %d\n", A);
        printf("negative(A) = %d\n", negative(A));
    }
    if (A < B) return 0;
    return 1;
}
int main(){
    divide(-2147483648, -1);
}

当它在没有编译器优化的情况下编译时，它会产生预期的结果。

gcc  -Wall -Werror -g -o TestNegative TestNegative.c
./TestNegative
A = -2147483648
negative(A) = 1
A = -2147483648
negative(A) = 1

当使用编译器优化对其进行编译时，会产生以下错误输出。

gcc -O3 -Wall -Werror -g -o TestNegative TestNegative.c
./TestNegative 
A = -2147483648
negative(A) = 1
A = -2147483648
negative(A) = 0

我正在运行gcc 5.4.0版。

我是否可以在源代码中进行更改，以防止编译器在-O3下产生这种行为？

Answer 1

详细解释这里发生的事情：

>

在这个答案中，我假设long是32位，long long是64位。这是最常见的情况，但不能保证。

C没有有符号整数内容。-2147483648实际上是long long类型，您在其上应用一元减号运算符。

• 在int中？不，它不能。
• 在long中？不，它不能。
• 在long long中？是的，它可以。因此，整数常量的类型将是long long。然后在那个long long上应用一元减号。

下一个棘手的部分是函数negative，在这里使用0x8000000。这也不是一个int，也不是一个long，而是一个无符号int（请参见此处了解解释）。

将传递的int与无符号int进行比较时，“常用算术转换”（见此）强制将int隐式转换为无符号int。在这种特定情况下，它不会影响结果，但这就是为什么gcc-Wconversion用户在这里得到了一个很好的警告。

（提示：已经启用-Wconversion！它有助于捕捉细微的bug，但不是-Wall或-Wextra的一部分）

接下来执行~A，这是值的二进制表示形式的一个按位反转，结果是值0x7FFFFFFF。事实证明，这与32位或64位系统上的INT_MAX值相同。因此，0x7FFFFFFF 1给出一个有符号整数溢出，从而导致未定义的行为。这就是该项目行为不端的原因。

厚颜无耻地，我们可以将代码更改为A=~A 1u；，突然一切都按预期工作，这也是因为隐式整数提升。

经验教训：

在C语言中，整数常量以及隐式整数提升是非常危险和不直观的。它们可以微妙地完全改变程序的含义，并引入错误。在C语言中的每个操作中，都需要考虑所涉及的操作数的实际类型。

玩转C11_Generic可能是查看实际类型的好方法。示例：

#define TYPE_SAFE(val, type) _Generic((val), type: val)
...
(void) TYPE_SAFE(-2147483648, int); // won't compile, type is long or long long
(void) TYPE_SAFE(0x80000000, int);  // won't compile, type is unsigned int

保护自己免受此类错误侵害的良好安全措施是始终使用stdint. h并使用MISRA-C。

Answer 2

编译器将您的A=~A 1；语句替换为单个neg指令，即此代码：

int just_negate(int A) {
    A = ~A + 1;
    return A;
}

将被汇编为：

just_negate(int):
  mov eax, edi
  neg eax         // just negate the input parameter
  ret

但是，编译器也足够聪明，可以实现这一点，如果A

这意味着第二个printf（“负（A）=%d\n”，负（A）） 可以“安全”优化为：

mov edi, OFFSET FLAT:.LC0    // .string "negative(A) = %d\n"
xor eax, eax                 // just set eax to zero
call printf

我使用在线Godbolt编译器资源管理器来检查程序集是否进行了各种编译器优化。

Answer 3

>

A=~A 1；调用未定义的行为，因为~A 1会导致整数溢出。

这不是编译器，而是你的代码。