From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7982 invoked by alias); 22 Feb 2012 21:44:42 -0000 Received: (qmail 7966 invoked by uid 22791); 22 Feb 2012 21:44:40 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_JS X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 22 Feb 2012 21:44:26 +0000 From: "jsm28 at gcc dot gnu.org" To: glibc-bugs@sources.redhat.com Subject: [Bug math/887] Math library function "logb" and "nextafter" inconsistent Date: Wed, 22 Feb 2012 21:44:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: math X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jsm28 at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: rsa at us dot ibm.com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-02/txt/msg00381.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=887 --- Comment #10 from Joseph Myers 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.