Re: [BZ #15442][PATCH] MIPS/glibc: soft-fp NaN representation corrections

["Maciej W. Rozycki" <macro at codesourcery dot com>]

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 
> <http://sourceware.org/ml/libc-ports/2013-04/msg00008.html> 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.<arch> 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