On Wed, Mar 14, 2012 at 4:42 PM, Bastien ROUCARIES <roucaries.bast...@gmail.com> wrote: > On Wed, Mar 14, 2012 at 11:22 AM, Michael Goffioul > <michael.goffi...@gmail.com> wrote: >> On Wed, Mar 14, 2012 at 9:48 AM, Bruno Haible <br...@clisp.org> wrote: >>> Michael Goffioul wrote: >>>> I encountered a compilation error with MSVC when compiling floor.c in >>>> strict floating-point mode (-fp:strict). >>> >>> Note that the use of -fp:strict also leads to test failures such as >>> >>> test-hypot.h:41: assertion failed >>> FAIL: test-hypotl.exe >>> >>> MSVC appears to compile the test code (test-hypotl.c) in a different way, >>> in such a way that a comparison of +Inf with +Inf fails. >>> >>> I'm therefore not sure this option can be recommended. >> >> Initially I didn't use it, until I noticed a test failure in octave. >> At some point, 2 complex numbers are compared with '<': in octave, >> this is implemented by comparing the modules, then the arguments. >> However, the result of b < a was true while a and b were the same. >> This boiled down to rounding error accumulation in the FPU and the >> only way to avoid it was to use -fp:strict. According to MSVC >> documentation, this is the only way to get IEEE compliance >> (http://msdn.microsoft.com/en-us/library/ms235601(v=vs.100).aspx) and >> this is required in a software like octave. > > MSVC is broken for floating point comparaison see for instance > https://connect.microsoft.com/VisualStudio/feedback/details/518015/nan-comparison-under-the-64-bit-compiler-is-incorrect
Thanks, but I fail to see how this can apply to my situation. The link above is about NaN comparison on 64 bits compiler with -fp:fast. The comparison problem I'm experiencing is about non-NaN values on 32 bits compiler with -fp:precise. Or do you deduce from the link above that floating point comparison is globally broken? Michael.
