I have a simple piece of code that extracts a float from a FORTRAN-generated REAL array, and then inserts it into a stream for logging. Although this works for the first 30 cases, on the 31st it crashes with a "Floating-point invalid operation".
The code is:
int FunctionDeclaration(float* mrSwap)
swap_float = *(mrSwap+30-1);
message_stream << 30 << "\t" << swap_float << "\tblah blah blah \t";
individual entries may not be populated - but to the best of my understanding, this would just mean that swap_float would be set to a random float?
Emphatically not. Certain bit patterns in an IEEE floating-point number indicate an invalid number -- for instance, the result of an overflowing arithmetic operation, or an invalid one (such as 0.0/0.0). The puzzling thing here is that the debugger apparently accepts the number as valid, while
Try getting the bit layout of
swap_float. On a 32-bit system:
int i = *(int*)&swap_float;
i in hexadecimal, and let us know what you see.
Updated to add: From Mike's comment, i=1238430338, which is 49D0F282 in hex. This is a valid floating-point number, equal to exactly 1711696.25. So I don't know what's going on, I'm afraid. The only thing I can suggest is that maybe the compiler is loading the invalid floating-point number directly from the
mrSwap array into the floating-point register bank, without going through
swapFloat. So the true value of
swapFloat is simply not available to the debugger. To check this, try
int j = *(int*)(mrSwap+30-1);
and tell us what you see.
Updated again to add: Another possibility is a delayed floating-point trap. The floating-point co-processor (built into the CPU these days) generates a floating-point interrupt because of some illegal operation, but the interrupt doesn't get noticed until the next floating-point operation is attempted. So this crash might be a result of the previous floating-point operation, which could be anywhere. Good luck with that...