How does the cout statement affect the O/P of the code written?

Question

#include <iostream>
#include <iomanip>
#include <math.h>
using namespace std;

int main() {
    int t;
    double n;
    cin>>t;
    while(t--)
    {
        cin>>n;
        double x;
        for(int i=1;i<=10000;i++)
        {
            x=n*i;
            if(x==ceilf(x))
            {
                cout<<i<<endl;
                break;
            }
        }
    }
    return 0;
}

For I/P:

3
5
2.98
3.16

O/P:

1

If my code is:

#include <iostream>
#include <iomanip>
#include <math.h>
using namespace std;

int main() {
    int t;
    double n;
    cin>>t;
    while(t--)
    {
        cin>>n;
        double x;
        for(int i=1;i<=10000;i++)
        {
            x=n*i;
            cout<<"";//only this statement is added;
            if(x==ceilf(x))
            {
                cout<<i<<endl;
                break;
            }
        }
    }
    return 0;
}

For the same input O/P is:

1
50
25

The only extra line added in 2nd code is: cout<<"";

Can anyone please help in finding why there is such a difference in output just because of the cout statement added in the 2nd code?

Answer 1

Well this is a veritable Heisenbug. I've tried to strip your code down to a minimal replicating example, and ended up with this (http://ideone.com/mFgs0S):

#include <iostream>
#include <math.h>

using namespace std;

int main()
{
    float n;
    cin >> n;  // this input is needed to reproduce, but the value doesn't matter
    n = 2.98;  // overwrite the input value
    cout << "";  // comment this out => y = z = 149
    float x = n * 50;   // 149
    float y = ceilf(x); // 150
    cout << "";  // comment this out => y = z = 150
    float z = ceilf(x); // 149
    cout << "x:" << x << " y:" << y << " z:" << z << endl;
}

The behaviour of ceilf appears to depend on the particular sequence of iostream operations that occur around it. Unfortunately I don't have the means to debug in any more detail at the moment, but maybe this will help someone else to figure out what's going on. Regardless, it seems almost certain that it's a bug in gcc-4.9.2 and gcc-5.1. (You can check on ideone that you don't get this behaviour in gcc-4.3.2.)