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

v1.0 (example)
open
nobody
None
5
3 days ago
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 3 days ago
  • Hendrik Leppkes

    Hendrik Leppkes - 3 days ago

    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.

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks