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
