NaN handled differently in different g++ versions

Consider the following program, which is obviously buggy:

#include <cstdio>

double test(int n) {
    if (n % 2 == 0)
        return 0.0;
    // warning: control reaches end of non-void function
}

int main开发者_如何学编程() {
    printf("%.9lf\n", test(0));
    printf("%.9lf\n", test(1));
    printf("%.9lf\n", test(2));
    printf("%.9lf\n", test(3));
    return 0;
}

When compiled with g++, version 4.2.4 (Ubuntu 4.2.4-1ubuntu4) on a 32-bit Ubuntu 8.04, it produces the following output:

0.000000000
nan
0.000000000
nan

When compiled with g++, version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) on a 64-bit Ubuntu 10.04, it produces the following output:

0.000000000
0.000000000
0.000000000
0.000000000

It seems that the older compiler does some extra work in order to return NaN instead of garbage, while the newer compiler simply returns whatever there is in memory. What exactly causes this difference in behavior and how to control it and make it predictable across different compiler versions?

EDIT: Sorry for not mentioning undefined behavior earlier. I know that the difference comes from the fact that this program has undefined behavior. What I'd like to know why the former gcc version seems to put some effort and produce code that consistently returns NaN and when this behavior changed to the one observed in the latter gcc version. Also, by "predictable" I meant not how to write good programs in C++, but how to control this gcc behavior (maybe with some command line options?).

The code you show has undefined behavior, by failing to return a value in test from all control paths.

There is nothing to expect, and nothing you can do to control it, except by writing a correct program in the first place.

EDIT: I maintain that you shouldn't rely on what the compiler seems to do.

Even if you think you should, you shouldn't.

Looking at the dissasembly will reveal what this particular piece of code will be compiled into, but you will not be able to generalize to anything else than this particular piece of code, especially in the presence of optimizations. Undefined behavior really means what you think it does: unless you happen to master GCC's codebase, there will be no guarantee that what you observe will be reproducible in another context.

The only sensible solution here is to compile with -Wall and fix those "not all return paths return a value", so that the behaviour is 1) defined, 2) defined by you.

Your function returns double yet when n % 2 != 0 it isn't returning anything.

You are in the land of undefined behavior.

What I'd like to know why the former gcc version seems to put some effort and produce code that consistently returns NaN and when this behavior changed to the one observed in the latter gcc version. Also, by "predictable" I meant not how to write good programs in C++, but how to control this gcc behavior (maybe with some command line options?).

Because you're in the realm of undefined behavior, it is highly unlikely that there is any why. Compiler writers (justifiably) tend to not spend any effort on what a compiler does in cases of undefined behavior. Whatever happens here is almost certainly emergent behavior from (apparently) unrelated changes between the compiler versions, not a deliberate choice on the part of any compiler engineer. There is not going to be a flag to change it. Do not depend on it. Fix your code.

Ignore the warnings at your peril.

if (n % 2 == 0) return 0.0; else return 0.0;

Works properly, otherwise, in half the cases test() returns garbage.

And undefined behavior is version independent as I get NaNs also:

$ gcc --version
gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2
$ uname -a
Linux tallguy 2.6.38-8-generic #42-Ubuntu SMP Mon Apr 11 03:31:50 UTC 2011 i686 i686 i386 GNU/Linux