From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9062 invoked by alias); 24 Apr 2013 21:24:20 -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 9014 invoked by uid 89); 24 Apr 2013 21:24:19 -0000 X-Spam-SWARE-Status: No, score=-4.8 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; Wed, 24 Apr 2013 21:24:18 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1UV7Am-00053F-Uu from joseph_myers@mentor.com ; Wed, 24 Apr 2013 14:24:16 -0700 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Apr 2013 14:24:16 -0700 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.2.247.3; Wed, 24 Apr 2013 22:24:14 +0100 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.76) (envelope-from ) id 1UV7Aj-0007SM-Lw; Wed, 24 Apr 2013 21:24:13 +0000 Date: Wed, 24 Apr 2013 21:24:00 -0000 From: "Joseph S. Myers" To: "Maciej W. Rozycki" CC: , Subject: Re: [PATCH] MIPS/glibc: soft-fp NaN representation corrections In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2013-04/txt/msg00102.txt.bz2 On Wed, 24 Apr 2013, Maciej W. Rozycki 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. 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). 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. The patch itself looks fine to me, but I think someone else should review it as well. -- Joseph S. Myers joseph@codesourcery.com