Question

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.

Answer 1

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.