c++ - gcc优化？漏洞？及其对项目的实际意义

Question

我的问题分为三个部分

问题一
考虑下面的代码，

#include <iostream>
using namespace std;

int main( int argc, char *argv[])
{

    const int v = 50;
    int i = 0X7FFFFFFF;

    cout<<(i + v)<<endl;

    if ( i + v < i )
    {
        cout<<"Number is negative"<<endl;
    }
    else
    {
        cout<<"Number is positive"<<endl;
    }

    return 0;
}

No specific compiler optimisation options are used or the O's flag is used. It is basic compilation command g++ -o test main.cpp is used to form the executable.

看似非常简单的代码，在 SUSE 64 位操作系统 gcc 4.1.2 中有奇怪的行为。预期输出为“Number is negative”，而仅在 SUSE 64 位操作系统中，输出为“Number is positive”。

经过一些分析并对代码进行“disass”后，我发现编译器按以下格式进行了优化 -

• 由于i在比较的两边都相同，所以不能在同一个表达式中改变，从等式中去掉'i'。
• 现在，比较结果是 if ( v < 0 ) ，其中 v 是正常数，因此在编译过程中，else 部分 cout 函数地址被添加到寄存器中。找不到 cmp/jmp 指令。

我看到该行为仅在 gcc 4.1.2 SUSE 10 中出现。在 AIX 5.1/5.3 和 HP IA64 中尝试时，结果符合预期。

上面的优化是否有效？
或者，对 int 使用溢出机制不是有效的用例吗？

问题二
现在，当我从 if (i + v < i) 更改条件语句时至 if ( (i + v) < i )即使那样，行为也是一样的，至少我个人不同意这一点，因为提供了额外的大括号，我希望编译器创建一个临时的内置类型变量并进行比较，从而使优化无效。

问题三
假设我有一个庞大的代码库，我迁移了我的编译器版本，这样的错误/优化可能会对我的系统行为造成严重破坏。当然从业务角度来说，仅仅因为编译器升级就把所有代码行都重新测试一遍是非常没有效果的。

我认为出于所有实际目的，这些类型的错误很难(在升级期间)捕获，并且总是会泄露到生产站点。

谁能建议任何可能的方法来确保这些错误/优化不会对我现有的系统/代码库产生任何影响？

---

附言:

• 当 v 的常量从代码中移除时，编译器就不会进行优化。
• 我相信，使用溢出机制来查找变量是否来自 MAX - 50 值(在我的例子中)是完全没问题的。

---

更新(1)
我想达到什么目的？变量 i 将是一个计数器(一种 syncID)。如果我进行离线操作(50 次操作)，那么在启动期间，我想重置我的计数器，为此我正在检查边界值(以重置它)而不是盲目地添加它。

我不确定我是否依赖于硬件实现。我知道 0X7FFFFFFF 是最大正值。我所做的就是，通过为此增加值(value)，我期望返回值为负。我不认为这个逻辑与硬件实现有任何关系。

无论如何，非常感谢您的投入。

---

更新(2)
大多数 inpit 声明我依赖于溢出检查的较低级别行为。我有一个关于相同的问题，

• 如果是这种情况，对于无符号整数，我如何在下溢或溢出期间验证和重置值？就像 v=10，i=0X7FFFFFFE，我想重置 i = 9。同样对于下溢？

除非我检查数字的负性，否则我无法做到这一点。所以我的主张是，当一个值被添加到 +MAX_INT 时，int 必须返回一个负数。

请让我知道您的意见。

Answer 1

这是一个已知问题，我不认为它是编译器中的错误。当我用 gcc 4.5 和 -Wall -O2 编译时它警告

warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false

尽管您的代码确实溢出了。

您可以传递 -fno-strict-overflow 标志来关闭该特定优化。