Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180814002653.12828-1-richard.hender...@linaro.org
Subject: [Qemu-devel] [PATCH 0/4] target/arm: Fix int64_to_float16
double-rounding
=== TEST SCRIPT BEGIN ===
#!/bin/bash
On 14 August 2018 at 01:26, Richard Henderson
wrote:
> In 88808a022c0, I tried to fix an overflow problem that affected float16
> scaling by coverting first to float64 and then rounding after that.
>
> However, Laurent reported that -0x3ff401 converted to float16
> resulted in 0xfbfe inste
Hi,
This series seems to have some coding style problems. See output below for
more information:
Type: series
Message-id: 20180814002653.12828-1-richard.hender...@linaro.org
Subject: [Qemu-devel] [PATCH 0/4] target/arm: Fix int64_to_float16
double-rounding
=== TEST SCRIPT BEGIN ===
#!/bin/bash
Richard Henderson writes:
> On 08/14/2018 01:32 AM, Alex Bennée wrote:
>> Can't we add the constants to the fcvt test case?
>
> No, they're all half-to-integer. This is integer-to-half.
I'll add the int-to-float conversions, the whole thing could do with a
bit of a re-factor anyway.
>
> We c
On 08/14/2018 01:32 AM, Alex Bennée wrote:
> Can't we add the constants to the fcvt test case?
No, they're all half-to-integer. This is integer-to-half.
We could write another one, I suppose, but it's not just
an add-one-line kind of thing.
r~
Richard Henderson writes:
> In 88808a022c0, I tried to fix an overflow problem that affected float16
> scaling by coverting first to float64 and then rounding after that.
>
> However, Laurent reported that -0x3ff401 converted to float16
> resulted in 0xfbfe instead of the expected 0xfbf
In 88808a022c0, I tried to fix an overflow problem that affected float16
scaling by coverting first to float64 and then rounding after that.
However, Laurent reported that -0x3ff401 converted to float16
resulted in 0xfbfe instead of the expected 0xfbff. This is caused by
the inexact con