On Fri, 1 May 2020, Alex Bennée wrote:
> I still see some failures for:
>
> f64_to_extF80
> f128_to_extF80
Running what I think are those tests, I see e.g.
./fp-test -s -l 1 -r all f64_to_extF80
>> Testing f64_to_extF80
768 tests total.
Errors found in f64_to_extF80:
-368.FFFF8000000FF
=> -3F68.FFFFC0000007F800 ..... expected -3F68.FFFFC00000000000 ....x
which looks like it's a test of the floatx80 format with 24-bit precision.
If that's what this is testing, then:
(a) float64_to_floatx80 would need, in 24-bit mode, to call
roundAndPackFloatx80 rather than just packFloatx80, to get appropriate
rounding;
(b) float128_to_floatx80 would need to use the dynamically specified
rounding precision in its call to roundAndPackFloatx80 instead of
hardcoded 80;
(c) but i386 instruction semantics are that a load of a double value into
a floating-point register, in the 24-bit mode, does *not* convert the
significand to 24-bit precision, but loads the full 53-bit-precision value
into the register, so making such a change to float64_to_floatx80 would
render it incorrect for i386 emulation without changes to the target/i386
code to adjust the rounding precision used for loads;
(d) float128_to_floatx80 shouldn't actually be used by any QEMU target,
because no supported CPU architecture has support for both formats in
hardware (although I made my sNaN change to the conversions between them
anyway for completeness).
--
Joseph S. Myers
jos...@codesourcery.com
