[Bug math/30973] New: totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[Bug math/30973] New: totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30973

            Bug ID: 30973
           Summary: totalorder compares quiet NaN and signalling NaN
                    incorrectly on sh4
           Product: glibc
           Version: 2.35
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: math
          Assignee: unassigned at sourceware dot org
          Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 15170
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15170&action=edit
test case for float

The bit that distinguishes a quiet NaN from a signalling NaN is,
according to <https://en.wikipedia.org/wiki/NaN#Encoding>, the most
significant bit of the mantissa field.  This bit is
*  == 0 to indicate a quiet NaN or Infinity,
   == 1 to indicate a signalling NaN,
   on these CPUs: hppa, mips, sh4.
*  == 1 to indicate a quiet NaN,
   == 0 to indicate a signalling NaN or Infinity,
   on all other CPUs.

The statement regarding sh4 follows from the "SH-4 Software Manual"
<https://www.renesas.com/us/en/document/mas/sh-4-software-manual>
page 143.

The totalorder* functions in glibc 2.35 get this distinction wrong.

How to reproduce:

Compile and run the attached programs in the Linux/sh4 QEMU user-mode
environment. I use QEMU version 8.0.2.

$ sh4-linux-gnu-gcc-11 -Wall test-totalorderf.c -lm
$ ./a.out
Failed: i=0 j=1
Failed: i=1 j=0
Failed: i=12 j=13
Failed: i=13 j=12

$ sh4-linux-gnu-gcc-11 -Wall test-totalorder.c -lm
$ ./a.out
Failed: i=0 j=1
Failed: i=1 j=0
Failed: i=12 j=13
Failed: i=13 j=12

$ sh4-linux-gnu-gcc-11 -Wall test-totalorderl.c -lm
$ ./a.out
Failed: i=0 j=1
Failed: i=1 j=0
Failed: i=12 j=13
Failed: i=13 j=12

For documentation how the totalorder* functions are supposed to behave,
refer to
https://www.gnu.org/software/libc/manual/html_node/FP-Comparison-Functions.html
or
https://lists.gnu.org/archive/html/bug-gnulib/2023-10/msg00037.html

For insight into the floating-point number representation on this
platform, compile and run the attached foo*.c programs in the Linux/sh4
QEMU user-mode environment.

$ sh4-linux-gnu-gcc-11 foof.c
$ ./a.out 
Bits: 32
Mantissa bits: 24
Min exponent: -125
Max exponent:  128
1.0 representation:         00 00 80 3F
1/3 representation:         AB AA AA 3E
+Infinity representation:   00 00 80 7F
-Infinity representation:   00 00 80 FF
qNaN representation:        FF FF BF 7F

$ sh4-linux-gnu-gcc-11 food.c
$ ./a.out 
Bits: 64
Mantissa bits: 53
Min exponent: -1021
Max exponent:  1024
1.0 representation:         00 00 00 00 00 00 F0 3F
1/3 representation:         55 55 55 55 55 55 D5 3F
+Infinity representation:   00 00 00 00 00 00 F0 7F
-Infinity representation:   00 00 00 00 00 00 F0 FF
qNaN representation:        FF FF FF FF FF FF F7 7F

$ sh4-linux-gnu-gcc-11 fool.c
$ ./a.out 
Bits: 64
Mantissa bits: 53
Min exponent: -1021
Max exponent:  1024
1.0 representation:         00 00 00 00 00 00 F0 3F
1/3 representation:         55 55 55 55 55 55 D5 3F
+Infinity representation:   00 00 00 00 00 00 F0 7F
-Infinity representation:   00 00 00 00 00 00 F0 FF
qNaN representation:        FF FF FF FF FF FF F7 7F

The row "qNaN representation" shows the value of 0.0 / 0.0, as computed
by QEMU. As you can see, it is consistent with the "SH-4 Software Manual"
<https://www.renesas.com/us/en/document/mas/sh-4-software-manual>
page 143.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30973] totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30973

--- Comment #1 from Bruno Haible <bruno at clisp dot org> ---
Created attachment 15171
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15171&action=edit
test case for double

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30973] totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30973

--- Comment #2 from Bruno Haible <bruno at clisp dot org> ---
Created attachment 15172
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15172&action=edit
test case for long double

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30973] totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30973

--- Comment #3 from Bruno Haible <bruno at clisp dot org> ---
Created attachment 15173
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15173&action=edit
insights about float

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30973] totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30973

--- Comment #4 from Bruno Haible <bruno at clisp dot org> ---
Created attachment 15174
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15174&action=edit
insights about double

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30973] totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30973

--- Comment #5 from Bruno Haible <bruno at clisp dot org> ---
Created attachment 15175
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15175&action=edit
insights about long double

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30973] totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[bruno at clisp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30973

Bruno Haible <bruno at clisp dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Host|                            |sh4-linux-gnu

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30973] totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30973

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #6 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
We do have qNaN and sNaN tests for totalorder, for all supported float types:

math/libm-test-totalorder.inc

 92     TEST_fpfp_b (totalorder, snan_value, qnan_value, 1,
NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
 93     TEST_fpfp_b (totalorder, snan_value, -qnan_value, 0,
NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
 94     TEST_fpfp_b (totalorder, -snan_value, qnan_value, 1,
NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),
 95     TEST_fpfp_b (totalorder, -snan_value, -qnan_value, 0,
NO_INEXACT_EXCEPTION|ERRNO_UNCHANGED),

And at least with qemu they do not show any failure on SH4:

sh4-linux-gnu$ math/test-float-totalorder
testing float (without inline functions)

Test suite completed:
  712 test cases plus 354 tests for exception flags and
    354 tests for errno executed.
  All tests passed successfully.
sh4-linux-gnu$ math/test-double-totalorder
testing double (without inline functions)

Test suite completed:
  792 test cases plus 394 tests for exception flags and
    394 tests for errno executed.
  All tests passed successfully.
sh4-linux-gnu$ math/test-ldouble-totalorder
testing long double (without inline functions)

Test suite completed:
  792 test cases plus 394 tests for exception flags and
    394 tests for errno executed.
  All tests passed successfully.

(the tests were built with --enable-hardcoded-path-in-tests, which sets the
loader path to one built, and adds all the internal path on rpath)

The sh uses the generic totalorder implementation:

  sysdeps/ieee754/flt-32/s_totalorderf.c
  sysdeps/ieee754/dbl-64/s_totalorder.c

And both implementation already handles the signaling NaN position through the
HIGH_ORDER_BIT_IS_SET_FOR_SNAN flag:

sysdeps/ieee754/dbl-64/s_totalorder.c

 33 #if HIGH_ORDER_BIT_IS_SET_FOR_SNAN
 34   /* For the preferred quiet NaN convention, this operation is a
 35      comparison of the representations of the arguments interpreted as
 36      sign-magnitude integers.  If both arguments are NaNs, invert the
 37      quiet/signaling bit so comparing that way works.  */
 38   if ((ix & 0x7fffffffffffffffULL) > 0x7ff0000000000000ULL
 39       && (iy & 0x7fffffffffffffffULL) > 0x7ff0000000000000ULL)
 40     {
 41       ix ^= 0x0008000000000000ULL;
 42       iy ^= 0x0008000000000000ULL;
 43     }
 44 #endif

However only hppa and mips (without __mips_nan2008 ABI) defines it to 1.  The
glibc tests use the compiler building __builtin_nans ("") to create a constant
signaling NaN and with our foof.c program:

[...]
union u construct_signalling_nan (float quiet_value)
{
  union u m;
  m.value = quiet_value;
  /* Turn the quiet NaN into a signalling NaN.  */
  m.word ^= (uint32_t) 1 << 22;
  /* Set some arbitrary mantissa bit.  */
  m.word |= (uint32_t) 1;
  return m;
}
[...]
  x.value = __builtin_nansf ("");
  show_representation ("sNaN", &x);

  x = construct_signalling_nan (x.value);
  show_representation ("sNan (C)", &x);
[...]

$ sh4-glibc-linux-gnu-gcc -E -dD - < /dev/null  | grep __SH_FPU_
#define __SH_FPU_ANY__ 1
#define __SH_FPU_DOUBLE__ 1

$ ./elf/ld.so --library-path .:math ./foof
qNaN representation:        FF FF BF 7F
sNaN representation:        00 00 A0 7F
sNan (C) representation:    FF FF FF 7F

So the compiler is not using the mantissa MSB 1 to define a sNaN, as you are
stating.

And this seems really to be what hardware defines, the 2.33 release page [1]
has the last result I did on real hardware and I haven't seen any failure
regarding totalorder. It means that the glibc assumption that SH4 FPU does not
set the MSB to indicate an SNAN seems correct.


[1] https://sourceware.org/glibc/wiki/Release/2.33#SH

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30973] totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30973

--- Comment #7 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
So the question is whether both the GCC and glibc are assuming sNAN encoding is
wrong on SH4, and tests are not catching it.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30973] totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30973

--- Comment #8 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
And I think on the foof.c test, trying to construct the qNaN as:

  a = 0.0;
  b = 0.0;
  init_representation (&x);
  x.value = a / b;
  show_representation ("qNaN", &x);

will actually generate a sNaN.  You can check that if you force evaluation
with:

#define math_force_eval(x)                                              \
  ({ __typeof (x) __x = (x); __asm __volatile__ ("" : : "m" (__x)); })

it will generate the same output.  On glibc tests, we generate qNaN also with
compiler builtins to avoid such issues (__builtin_nan{f,l}).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30973] totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30973

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=111814

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30973] totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30973

--- Comment #9 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Adhemerval Zanella from comment #8)
> And I think on the foof.c test, trying to construct the qNaN as:
> 
>   a = 0.0;
>   b = 0.0;
>   init_representation (&x);
>   x.value = a / b;
>   show_representation ("qNaN", &x);
> 
> will actually generate a sNaN.  You can check that if you force evaluation
> with:
> 
> #define math_force_eval(x)                                              \
>   ({ __typeof (x) __x = (x); __asm __volatile__ ("" : : "m" (__x)); })
> 
> it will generate the same output.  On glibc tests, we generate qNaN also
> with compiler builtins to avoid such issues (__builtin_nan{f,l}).

Scratch that, this generates a qNaN indeed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30973] totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30973

--- Comment #10 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Adhemerval Zanella from comment #7)
> So the question is whether both the GCC and glibc are assuming sNAN encoding
> is wrong on SH4, and tests are not catching it.

Sigh... it seems that you are right and we will need to set
HIGH_ORDER_BIT_IS_SET_FOR_SNAN.  However, I am not sure how to properly handle
it on glibc; since the compiler itself has been generating wrong builtins
constants for a lot of time.  

It means that if we change HIGH_ORDER_BIT_IS_SET_FOR_SNAN to 1 on glibc, older
binaries will start to handle sNaN incorrectly.  I am not sure if we will need
to add compat symbol for all affected ABI symbols, it won't help if you use a
recent gcc with older glibc.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug math/30973] totalorder compares quiet NaN and signalling NaN incorrectly on sh4

[joseph at codesourcery dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30973

--- Comment #11 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
https://sourceware.org/pipermail/libc-alpha/2018-February/091658.html has 
my previous remarks on things that would need changing to fix the NaN 
conventions used by GCC and glibc for SH.

-- 
You are receiving this mail because:
You are on the CC list for the bug.