* David Roundy: > definition of the variable and the comparison, this check may be > failed. The reason is that intermediate results are commonly stored
"commonly" = "on legacy i386 platforms" > at higher than double precision, leading to non-IEEE arithmetic. AFAIK, GCC's behavior is not in itself a contradiction to IEEE rules. > It's sad, but we're stuck with it, as I'm not aware of any compiler > that is capable of generating IEEE arithmetic. It's more a language definition issue. Ada, for instance, uses a model based on interval arithmetic, and the usual i386 extended precision arithmetic with occasional spilling still matches its requirements: 14. For any predefined relation on operands of a floating point type T, the implementation may deliver any value (i.e., either True or False) obtained by applying the (exact) mathematical comparison to values arbitrarily chosen from the respective operand intervals. In addition, there are C compilers which are not affected by this problem, even on the i386 architecture: Some of them use SSE2 arithmetic, some run the FPU in 64-bit mode (instead of 80-bit mode, very common on Windows). Or you can spill long doubles instead of doubles where necessary, or spill-and-reload early so that there is no observable difference (I believe Intel's compiler does one of these). _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users