[Bug math/887] Math library function "logb" and "nextafter" inconsistent

["jsm28 at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=887

--- Comment #10 from Joseph Myers <jsm28 at gcc dot gnu.org> 2012-02-22 21:43:55 UTC ---
Regarding logb and the sign of zero, IEEE 754-2008 says (section 5.3.3) that
"logB(1) is +0.".  I think that's a clear indication that glibc should not
return -0 from logb in any rounding mode.

Regarding nextafter, although there is a patch claiming to fix some problem I
see no statement of what the problem is (i.e. this is not a complete bug report
- and anyway a report for nextafter would best be a separate bug report). 
Anyway, 754-2008 doesn't appear to define nextafter, but it has nextUp and
nextDown.  Their results do not depend on rounding mode, so it appears that if
the two arguments to nextafter compare unequal and neither is NaN, then if the
result is zero it must have the sign of x independent of rounding mode.

Regarding conversion from integers to floating point, "Integer zeros without
signs are converted to +0." (754-2008, section 5.4.1).  So I think it is wrong
to convert them to -0 in round-downwards mode.  Of course this is only a GCC
bug if -frounding-math is used; otherwise GCC is entitled to assume
round-to-nearest.  If -frounding-math, I think GCC for 32-bit Power
Architecture needs to save and restore the rounding mode when doing these
conversions.

Then it would be possible to compile the logb code with -frounding-math.  There
would still be the question of any architecture-specific workaround for older
GCC, since a testcase for logb in different rounding modes ought to go in the
testsuite but you might not want older GCC to make the testsuite fail.

Ryan, are you actually still working on this?  If not, please unassign
yourself.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.