bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MSVC fails to compile floor.c with -fp:strict


From: Michael Goffioul
Subject: Re: MSVC fails to compile floor.c with -fp:strict
Date: Wed, 14 Mar 2012 16:53:43 +0000

On Wed, Mar 14, 2012 at 4:42 PM, Bastien ROUCARIES
<address@hidden> wrote:
> On Wed, Mar 14, 2012 at 11:22 AM, Michael Goffioul
> <address@hidden> wrote:
>> On Wed, Mar 14, 2012 at 9:48 AM, Bruno Haible <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]