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.800FF
On 5/1/20 9:17 AM, Alex Bennée wrote:
> Ideally we want to
> convert the extF80 and f128 code to use the newer FloatParts code which
> is pretty robustly tested now. However the trick would be finding a way
> to do that that doesn't involve break or regressing the performance for
> the f16/32/64 ca
Joseph Myers writes:
> Conversions between IEEE floating-point formats should convert
> signaling NaNs to quiet NaNs. Most of those in QEMU's softfloat code
> do so, but those for floatx80 fail to. Fix those conversions to
> silence signaling NaNs as well.
I realised we hadn't enabled float-
Joseph Myers writes:
> Conversions between IEEE floating-point formats should convert
> signaling NaNs to quiet NaNs. Most of those in QEMU's softfloat code
> do so, but those for floatx80 fail to. Fix those conversions to
> silence signaling NaNs as well.
>
> Signed-off-by: Joseph Myers
Th
Conversions between IEEE floating-point formats should convert
signaling NaNs to quiet NaNs. Most of those in QEMU's softfloat code
do so, but those for floatx80 fail to. Fix those conversions to
silence signaling NaNs as well.
Signed-off-by: Joseph Myers
---
fpu/softfloat.c | 24 +
