gcc优化？ bug？及其对项目的实际意义 [英] gcc optimization? bug? and its practial implication to project

问题描述

我的问题分为三部分

问题1

请考虑以下代码

  #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  {
 cout<<Number is negative<< endl; 
} 
 else 
 {
 cout<<Number is positive<< endl; 
} 
 
 return 0; 
} 
  

没有使用特定的编译器优化选项，使用O的标志。它是基本的编译命令g ++ -o test main.cpp用于形成可执行文件。

看起来很简单的代码，行为在SUSE 64位操作系统，gcc版本4.1.2。预期输出为数字为负，而只在SUSE 64位操作系统中，输出将为数字为正。

经过一些分析和做一个'反'的代码，我发现编译器以下面的格式优化 -

• ，它不能在同一个表达式中改变，从方程中删除'i'。
现在，比较导致 if（v< 0），其中v是常数正数，因此在编译期间，else部分cout函数地址被添加到寄存器。没有找到cmp / jmp说明。

我看到的行为只有在gcc 4.1.2 SUSE 10.当尝试AIX 5.1 / 5.3和HP IA64，结果如预期。

上述优化是否有效？

或者，

问题2

现在，当我更改了从 if（i + v 到 if（（i + v）< i）即使那样，行为是一样的，这至少我个人不同意，因为提供了额外的大括号，我希望编译器创建一个临时内置的类型变量，并且他们比较，从而使优化无效。

问题3

假设我有一个庞大的代码库，我迁移我的编译器版本，这样的错误/优化可能会导致我的系统行为。从业务角度来看，仅仅因为编译器升级而再次测试所有代码行是非常无效的。

我认为对于所有实用目的，这些类型的错误很难捕获（在升级期间），并且总是会泄漏到生产站点。

任何人都可以提出任何可能的方法来确保这些类型的错误/优化对我现有的系统/代码库没有任何影响。

---

PS：

< v从代码中删除，那么编译器不会进行优化。

• 我相信，使用溢出机制来找出变量是否来自MAX - 50值是完全正确的


我想要实现什么？变量i将是一个计数器（syncID的种类）。如果我做离线操作（50操作），然后在启动期间，我想重置我的计数器，因为这我检查边界值（重置它），而不是盲目添加。




我不知道我是否依靠硬件实现。我知道0X7FFFFFFF是最大正值。我所做的是，通过增加价值，我期望返回值为负。我不认为这个逻辑与硬件实现有任何关系。





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





---





更新（2）

大多数inpit我依赖于较低级别的行为对溢出检查。我有一个相同的问题，






• 如果是这样，对于unsigned int如何在下溢期间验证和重置值或溢出？喜欢如果v = 10，i = 0X7FFFFFFE，我想要重置i = 9.类似地，对于下溢？






我不能这样做，除非我检查数字的否定性。所以我的说法是，当一个值被添加到+ MAX_INT时，int必须返回一个负数。





请让我知道您的意见。

解决方案

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




警告：假设当假定（X + c）<1时不发生有符号溢出。 X总是假的




虽然你的代码有溢出。





您可以通过 -fno-strict-overflow 标志关闭该特定优化。




My questions are divided into three parts

Question 1
Consider the below code,

#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.

The seemingly very simple code, has odd behaviour in SUSE 64 bit OS, gcc version 4.1.2. The expected output is "Number is negative", instead only in SUSE 64 bit OS, the output would be "Number is positive".

After some amount of analysis and doing a 'disass' of the code, I find that the compiler optimises in the below format -

• Since i is same on both sides of comparison, it cannot be changed in the same expression, remove 'i' from the equation.
• Now, the comparison leads to if ( v < 0 ), where v is a constant positive, So during compilation itself, the else part cout function address is added to the register. No cmp/jmp instructions can be found.

I see that the behaviour is only in gcc 4.1.2 SUSE 10. When tried in AIX 5.1/5.3 and HP IA64, the result is as expected.

Is the above optimisation valid?
Or, is using the overflow mechanism for int not a valid use case?

Question 2
Now when I change the conditional statement from if (i + v < i) to if ( (i + v) < i ) even then, the behaviour is same, this atleast I would personally disagree, since additional braces are provided, I expect the compiler to create a temporary built-in type variable and them compare, thus nullify the optimisation.

Question 3
Suppose I have a huge code base, an I migrate my compiler version, such bug/optimisation can cause havoc in my system behaviour. Ofcourse from business perspective, it is very ineffective to test all lines of code again just because of compiler upgradation.

I think for all practical purpose, these kinds of error are very difficult to catch (during upgradation) and invariably will be leaked to production site.

Can anyone suggest any possible way to ensure to ensure that these kind of bug/optimization does not have any impact on my existing system/code base?

---

PS :

• When the const for v is removed from the code, then optimization is not done by the compiler.
• I believe, it is perfectly fine to use overflow mechanism to find if the variable is from MAX - 50 value (in my case).

---

Update(1)
What would I want to achieve? variable i would be a counter (kind of syncID). If I do offline operation (50 operation) then during startup, I would like to reset my counter, For this I am checking the boundary value (to reset it) rather than adding it blindly.

I am not sure if I am relying on the hardware implementation. I know that 0X7FFFFFFF is the max positive value. All I am doing is, by adding value to this, I am expecting the return value to be negative. I don't think this logic has anything to do with hardware implementation.

Anyways, all thanks for your input.

---

Update(2)
Most of the inpit states that I am relying on the lower level behavior on overflow checking. I have one questions regarding the same,

• If that is the case, For an unsigned int how do I validate and reset the value during underflow or overflow? like if v=10, i=0X7FFFFFFE, I want reset i = 9. Similarly for underflow?

I would not be able to do that unless I check for negativity of the number. So my claim is that int must return a negative number when a value is added to the +MAX_INT.

Please let me know your inputs.

解决方案

It's a known problem, and I don't think it's considered a bug in the compiler. When I compile with gcc 4.5 with -Wall -O2 it warns

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

Although your code does overflow.

You can pass the -fno-strict-overflow flag to turn that particular optimization off.

这篇关于gcc优化？ bug？及其对项目的实际意义的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！