[Bug math/18238] New: quality of implementation: fmin and fmax should handle signed zeros

[Bug math/18238] New: quality of implementation: fmin and fmax should handle signed zeros

[nszabolcs at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=18238

            Bug ID: 18238
           Summary: quality of implementation: fmin and fmax should handle
                    signed zeros
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: nszabolcs at gmail dot com

ISO C with Annex F seems to allow the result of fmax and fmin to have arbitrary
sign when the arguments are zeros, but ideally the sign should be handled
because these functions are supposed to have exact result.

http://port70.net/~nsz/c/c11/n1570.html#F.10.9.2

the code below outputs:

fmax(0, -0.0) signbit is not 0
fmaxf(0, -0.0f) signbit is not 0
fmaxl(-0.0L, 0) signbit is not 0
fmin(-0.0, 0) signbit is not 1
fminf(-0.0f, 0) signbit is not 1
fminl(0, -0.0L) signbit is not 1


#include <math.h>
#include <stdio.h>

#define T(f,s) if (signbit(f) != s) printf(#f " signbit is not " #s "\n");

int main()
{
T(fmax(0, -0.0), 0)
T(fmaxf(0, -0.0f), 0)
T(fmaxl(-0.0L, 0), 0)
T(fmin(-0.0, 0), 1)
T(fminf(-0.0f, 0), 1)
T(fminl(0, -0.0L), 1)
}

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/18238] quality of implementation: fmin and fmax should handle signed zeros

[jsm28 at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18238

Joseph Myers <jsm28 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #1 from Joseph Myers <jsm28 at gcc dot gnu.org> ---
These functions are only supposed to have results exact to the extent specified
in IEEE 754.  When both IEEE 754 and ISO C explicitly do not specify the sign
of a zero result, I don't think it's appropriate to slow down our
implementations to produce a more fully specified result.

-- 
You are receiving this mail because:
You are on the CC list for the bug.