Menu

#567 sqrt() no longer returns NaN for x less than -0

v1.0 (example)
closed-fixed
None
5
2017-09-05
2016-10-15
No

Using an old version of mingw-w64 (last updated May 2015), calling sqrt(-1.0) would return NaN (the expected result). After updating to the current version, it returns -1.0.

It looks like this bug was introduced by commit 6617eb.

The attached (untested) patch would likely fix it.

1 Attachments

Related

Bugs: #567

Discussion

  • Kai Tietz

    Kai Tietz - 2016-10-25

    Hello Martin,

    thanks for pointing us on this. There is a regression for sqrt on
    values classify(x) != NaN and x<-0. I prefer the following
    implementation more, as we avoid to split the if.

    if (x_class == FP_NAN || signbit (x))
    {
    if (x_class == FP_ZERO)
    return FLT_CST (-0.0);
    if ( x_class == FP_NAN )
    {
    FLT_RPT_DOMAIN ("sqrt", x, 0.0, x);
    return x;
    }
    res = -FLT_NAN;
    FLT_RPT_DOMAIN ("sqrt", x, 0.0, res);
    return res;
    }

    Regards,
    Kai

    2016-10-15 16:42 GMT+02:00 Martin Whitaker martinwhitaker@users.sf.net:


    [bugs:#567] sqrt() no longer returns NaN for x less than -0

    Status: open
    Group: v1.0 (example)
    Created: Sat Oct 15, 2016 02:42 PM UTC by Martin Whitaker
    Last Updated: Sat Oct 15, 2016 02:42 PM UTC
    Owner: nobody
    Attachments:

    sqrt.patch (656 Bytes; text/x-patch)

    Using an old version of mingw-w64 (last updated May 2015), calling
    sqrt(-1.0) would return NaN (the expected result). After updating to the
    current version, it returns -1.0.

    It looks like this bug was introduced by commit 6617eb.

    The attached (untested) patch would likely fix it.


    Sent from sourceforge.net because you indicated interest in
    https://sourceforge.net/p/mingw-w64/bugs/567/

    To unsubscribe from further messages, please visit
    https://sourceforge.net/auth/subscriptions/

     

    Related

    Bugs: #567

  • Daniel WEIL

    Daniel WEIL - 2017-02-01

    We've been faced with this bug since beginning of January as the official version of the i686-w64-mingw32-gcc cross compiler package with cygwin is gcc5.4. Quite annoying...

    I've made trials with different versions of mingw/gcc : OK on 5.3, KO on 5.4 (https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/5.4.0/threads-win32/sjlj/i686-5.4.0-release-win32-sjlj-rt_v5-rev0.7z)

    So we should not use the cross compiler delivered with cygwin until bug is corrected, and only use the 5.3 builds : https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/5.3.0/

    And all OCaml libraries compiled on Windows used this version of Gcc!

     

    Last edit: Daniel WEIL 2017-02-17
  • Hendrik Leppkes

    Hendrik Leppkes - 2017-02-17

    FFmpeg also has its FATE test suite failing due to this bug. It would be appreciated if this can be fixed and backported into the 5.x release branch as well.

     
  • zed

    zed - 2017-09-02

    It seems that bug is fixed in mingw-w64 7.1.

     
  • Hendrik Leppkes

    Hendrik Leppkes - 2017-09-02

    There is no such thing as 7.1, it is however fixed in mingw-w64 5.0.2

     
    • zed

      zed - 2017-09-02

      I installed and tested this: i686-7.1.0-release-posix-dwarf-rt_v5-rev2.7z (2017-08-12).

       

      Last edit: zed 2017-09-02
  • Zufu Liu

    Zufu Liu - 2017-09-04

    fixed in 7.1.0, gcc -v

    Thread model: posix
    gcc version 7.1.0 (x86_64-posix-seh-rev2, Built by MinGW-W64 project)
    
    D:\Download>gcc t1.c
    
    D:\Download>a
    -1.#IND00
    
    D:\Download>gcc -D__USE_MINGW_ANSI_STDIO t1.c
    
    D:\Download>a
    nan
    
    #include <stdio.h>
    #include <math.h>
    
    int main(void) {
        printf("%f\n", sqrt(-1));
        return 0;
    }
    
     
  • NightStrike

    NightStrike - 2017-09-05
    • status: open --> closed-fixed
    • assigned_to: Kai Tietz
     

Log in to post a comment.