Floating point exceptions

[tmcole]

How do I get my program to terminate with a traceback message when a computation produces NaN? I have selected level 0 under the floating point options and also checked floating point underflow, integer overflow, and power operations under the run time options in CVF6.6c, but my program does not end up with "denormalized" numbers set to zero. Rather, I get NaNs and the program merrily continues computing NaNs till the cows come home.

What is really weird about this is that when the program is compiled with debug options, the exception does not occur, but only with the optimized code, making me have to resort to print statements in the code.

[Steven_L_Intel1]

/fpe:0, with a main program compiled with that setting, should generate an exception if an arithmetic operation creates a NaN. But if you have some other problem that creates a NaN, such as overwriting a float with garbage, that wouldn't get caught.

[tmcole]

Steve, what specifically do you mean by overwriting a float with garbage? I have isolated the production of NaNs to when the code is compiled with no optimizations (but no debug information) on up through the highest. If I compile with debug options, or if I compile with no optimizations and array bounds checking, then no NaNs are produced. I thought I might have been overwriting by going out of bounds, but array bounds checking eliminates the problem. Any idea what might be causing this? Right now I'm looking for a "point in the right direction".

[Steven_L_Intel1]

It could be an argument mismatch, or something else. Try lowering the optimization level until the problem goes away, then raise it on selected sources to see if you can isolate the one (hopefully) that triggers the problem. This is a rather tedious debugging job, I'm sorry to say.

[tmcole]

How do I test for NaN in the code?

[Steven_L_Intel1]

You can use the ISNAN intrinsic. But I would probably do this in the debugger, watching the memory location to see when it changes to a NaN.

[tmcole]

But the problem doesn't occur when compiled with debug options.........

[Steven_L_Intel1]

See my note above about isolating the change. Often you can still debug the problem with a bit of work.

[tmcole]

The problem was 0.0**0.0, which the power operations run time check did not find.