gcc optimization? bug? and its practial implication to project

Posted by kumar_m_kiran on Stack Overflow See other posts from Stack Overflow or by kumar_m_kiran
Published on 2010-05-23T16:18:39Z Indexed on 2010/05/23 16:20 UTC
Read the original article Hit count: 240

Filed under:
|
|
|
|

Hi All,

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

© Stack Overflow or respective owner

Related posts about c++

Related posts about optimization