"Case Taintor" <casetaintor@xxxxxxxxx> writes: > I've been investigating this problem and ran across the > -funsafe-math-optimizations compile setting. By turning this > optimization on, we no longer get this special number. However, if we > were to get this special value again, the math bug would still be > there. There's very little about what exactly turning on this > optimization does, aside from a very short statement saying that it > may produce code that does not conform to IEEE or ANSI math rules. > What exactly does this mean? I know on some platforms you can enable > the FPU to use higher-precision numbers while the values exist in the > FPU registers (fp10.obj on windows does this), which could violate > IEEE rules. Is that the sort of thing that this optimization would > do? Any insight would be appreciated. The optimization enables things like permitting floating point computations to be reassociated, and permitting builtin math functions to assume that their arguments are in range. In general the code should run faster, but it will not follow the rules laid down in the IEEE floating point description. > My only real concern with turning this optimization on is if the > representation of a double in memory is changed (for instance, not > being normalized when it should be under IEEE rules). If it did this, > we could have some serious problems with 3rd party libraries. I doubt > this is the case, but I just would like to make sure. Also, the name > of the optimization is a bit... scary. The representation of the floating point numbers does not change when using -funsafe-math-optimizations. Ian
