gcc-O2的奇怪整数行为

strange integer behavior with gcc -O2

本文关键字：整数 gcc-O2      更新时间：2023-10-16
#include <stdio.h>
#include <limits.h>
void sanity_check(int x)
{
if (x < 0)
{
x = -x;
}
if (x == INT_MIN)
{
printf("%d == %dn", x, INT_MIN);
}
else
{
printf("%d != %dn", x, INT_MIN);
}
if (x < 0)
{
printf("negative number: %dn", x);
}
else
{
printf("positive number: %dn", x);
}
}
int main(void)
{
sanity_check(42);
sanity_check(-97);
sanity_check(INT_MIN);
return 0;
}

当我用gcc wtf.c编译上述程序时，我得到了预期的输出：

42 != -2147483648
positive number: 42
97 != -2147483648
positive number: 97
-2147483648 == -2147483648
negative number: -2147483648

然而，当我用gcc -O2 wtf.c编译程序时，我得到了不同的输出：

42 != -2147483648
positive number: 42
97 != -2147483648
positive number: 97
-2147483648 != -2147483648
positive number: -2147483648

注意最后两行。这到底是怎么回事？gcc 4.6.3是否过于急切地进行了优化？

(我也用g++4.6.3测试了这一点，我观察到了同样奇怪的行为，因此产生了C++标签。)

当您执行-(INT_MIN)时，您调用的是未定义的行为，因为该结果无法放入INT.

gcc-O2注意到x永远不可能是负数，并在此后进行优化。它不在乎你是否溢出了值，因为它是未定义的，它可以随心所欲地处理它。

我认为这可以帮助你，是从这里：这里

-fstrict溢出根据编译的语言，允许编译器采用严格的有符号溢出规则。对于C(和C++)来说，这意味着在用有符号数字进行算术时溢出是未定义的，也就是说编译器可能会认为不会发生这种情况。这允许进行各种优化。例如，编译器将假设像i+10>i这样的表达式对于有符号i将始终为true。只有当有符号溢出未定义时，这种假设才有效，因为当使用二进制补码算术时，如果i+10溢出，则表达式为false。当此选项生效时，任何确定有符号数字运算是否会溢出的尝试都必须小心写入，以免实际涉及溢出。此选项还允许编译器采用严格的指针语义：给定一个指向对象的指针，如果向该指针添加偏移量不会生成指向同一对象的指针则添加是未定义的。这允许编译器得出结论，对于指针p和无符号整数u，p+u>p始终为真。这一假设只有在指针环绕未定义的情况下才有效，因为如果p+u使用二进制补码运算溢出，则表达式为假。

另请参阅-fwrapv选项。使用-fwrapv意味着整数符号溢出是完全定义的：它进行包装。当使用-fwrapv时，整数的-fstrict溢出和-fno严格溢出没有区别。使用-fwrav时，允许某些类型的溢出。例如，如果编译器在对常量进行运算时发生溢出，则溢出的值仍然可以与-fwrapv一起使用，但不能用于其他情况。

-fstrict溢出选项在-O2、-O3和-Os级别启用。

相关文章：