We create our 128-bit default NaN by calling parts64_default_nan()
and then adjusting the result. We can do the same trick for creating
the floatx80 default NaN, which lets us drop a target ifdef.
floatx80 is used only by:
i386
m68k
arm nwfpe old floating-point emulation emulation support
(which is essentially dead, especially the parts involving floatx80)
PPC (only in the xsrqpxp instruction, which just rounds an input
value by converting to floatx80 and back, so will never generate
the default NaN)
The floatx80 default NaN as currently implemented is:
m68k: sign = 0, exp = 1...1, int = 1, frac = 1....1
i386: sign = 1, exp = 1...1, int = 1, frac = 10...0
These are the same as the parts64_default_nan for these architectures.
This is technically a possible behaviour change for arm linux-user
nwfpe emulation emulation, because the default NaN will now have the
sign bit clear. But we were already generating a different floatx80
default NaN from the real kernel emulation we are supposedly
following, which appears to use an all-bits-1 value:
https://elixir.bootlin.com/linux/v6.12/source/arch/arm/nwfpe/softfloat-specialize#L267
This won't affect the only "real" use of the nwfpe emulation, which
is ancient binaries that used it as part of the old floating point
calling convention; that only uses loads and stores of 32 and 64 bit
floats, not any of the floatx80 behaviour the original hardware had.
We also get the nwfpe float64 default NaN value wrong:
https://elixir.bootlin.com/linux/v6.12/source/arch/arm/nwfpe/softfloat-specialize#L166
so if we ever cared about this obscure corner the right fix would be
to correct that so nwfpe used its own default-NaN setting rather
than the Arm VFP one.
Signed-off-by: Peter Maydell<peter.maydell@linaro.org>
---
fpu/softfloat-specialize.c.inc | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)