From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20890 invoked by alias); 7 May 2013 19:39:24 -0000 Mailing-List: contact libc-ports-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: libc-ports-owner@sourceware.org Received: (qmail 20862 invoked by uid 89); 7 May 2013 19:39:20 -0000 X-Spam-SWARE-Status: No, score=-4.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL autolearn=ham version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 07 May 2013 19:39:18 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1UZnjJ-00052i-4o from Maciej_Rozycki@mentor.com ; Tue, 07 May 2013 12:39:17 -0700 Received: from SVR-IES-FEM-02.mgc.mentorg.com ([137.202.0.106]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 12:39:16 -0700 Received: from [172.30.64.24] (137.202.0.76) by SVR-IES-FEM-02.mgc.mentorg.com (137.202.0.106) with Microsoft SMTP Server id 14.2.247.3; Tue, 7 May 2013 20:39:13 +0100 Date: Tue, 07 May 2013 19:39:00 -0000 From: "Maciej W. Rozycki" To: "Joseph S. Myers" CC: Thomas Schwinge , , Subject: Re: [BZ #15442][PATCH] MIPS/glibc: soft-fp NaN representation corrections In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-05/txt/msg00034.txt.bz2 On Wed, 24 Apr 2013, Joseph S. Myers wrote: > > These changes touch generic code, for the most part. They are supposed > > not to affect targets other than MIPS, however I think it would make sense > > to test them at least on a selection of other targets glibc supports. > > However I am not familiar enough with other targets to know how much > > soft-fp is used across them; also I think automatic testing may have a > > better value than manually poking at a function or three. I will > > therefore appreciate ideas as to how to test these changes, or any other > > help with that indeed. > > I have run powerpc-nofpu testing with this patch applied and not seen any > NaN-related failures, and also confirmed that the generated libc/libm > binaries are unchanged by the patch. Thanks. > I would note that the test results would be better indicative of working > NaN handling if Thomas's patch > to test sNaN > inputs were checked in (minus the parts that as I noted were incorrect, > and with appropriate conditionals, with comments referencing filed bugs, > for cases that don't yet pass) - which it doesn't seem to be yet. > > I believe this patch should fix at least one user-visible bug regarding > sqrtl NaN handling (handling of input NaNs, and producing the correct sort > of NaN as output for negative input) - and this should show up as an > improvement on the test-ldouble results (although there will still be > plenty of failures there arising from use of fp-bit in libgcc not > supporting exceptions / rounding modes). These changes indeed cause the following progressions for New-ABI MIPS targets, thanks for the hint: --- test-ldouble.out 2013-05-02 02:36:49.138155826 +0100 +++ test-ldouble.out 2013-05-03 20:01:50.576925141 +0100 @@ -382,11 +382,6 @@ Failure: pow (-min_value, 0x1.ffffffffffffffffffffffffffffp+113) == +0: Exception "Underflow" not set Failure: pow (-min_value, max_value) == +0: Exception "Underflow" not set Failure: pow (2.0, -100000.0) == +0: Exception "Underflow" not set -Failure: sqrt (qNaN) == qNaN: Exception "Invalid operation" set -Failure: Test: sqrt (qNaN) == qNaN -Result: - is: sNaN - should be: qNaN Failure: Test: sqrt (-1) == qNaN Result: is: sNaN @@ -10028,4 +10023,4 @@ Test suite completed: 11156 test cases plus 10128 tests for exception flags executed. - 1986 errors occurred. + 1984 errors occurred. -- no progressions are seen for negative inputs because for those the result is passed from __kernel_standard (-lieee is not used by the test suite for some reason that I don't know; I think for the best results at least IEEE error handling should be tested in addition to the default of POSIX.1) that returns a double value and therefore has to be extended to a long double value with the aid of fp-bit that in turn has a bug in this area too (discussed here: http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00278.html). > If that bug isn't already in Bugzilla, it should be filed there. In any > case, the appropriate [BZ #N] notation should be used in the ChangeLog > entries (toplevel ChangeLog, and ports/ChangeLog.mips, not necessarily > other ports/ChangeLog. files although it's harmless to include it > there as well) to point to the bug, which should also be added to the > list of fixed bugs in NEWS as part of the fixing commit. I haven't found anything relevant, so this is now BZ #15442. > The patch itself looks fine to me, but I think someone else should review > it as well. I will appreciate that too -- ping? Maciej