Message ID | 20180510094206.15354-1-alex.bennee@linaro.org |
---|---|
Headers | show |
Series | refactor float-to-float and fix AHP | expand |
On 10 May 2018 at 10:42, Alex Bennée <alex.bennee@linaro.org> wrote: > Hi, > > Hi, > > I've not included the test case in the series but you can find it in > my TCG fixup branch: > > https://github.com/stsquad/qemu/blob/testing/tcg-tests-revival-v4/tests/tcg/arm/fcvt.c > > Some of the ARMv7 versions are commented out as they where not > supported until later revs. I do have a build that includes that but > unfortunately the Debian compiler it too old to build it. > > : patch 0001/fpu softfloat int_to_float ensure r fully initial.patch needs review > : patch 0004/target arm convert conversion helpers to fpst ahp.patch needs review > : patch 0005/target arm squash FZ16 behaviour for conversions.patch needs review This still seems to regress the NaN conversion case I mentioned in review of the previous series: (3) Here's a NaN case we get wrong now: 64 to IEEE-16 conversion, input is 0x7ff0000000000001 (an SNaN), we produce 0x7c00 (infinity) but should produce 0x7e00 (a QNaN). thanks -- PMM
Peter Maydell <peter.maydell@linaro.org> writes: > On 10 May 2018 at 10:42, Alex Bennée <alex.bennee@linaro.org> wrote: >> Hi, >> >> Hi, >> >> I've not included the test case in the series but you can find it in >> my TCG fixup branch: >> >> https://github.com/stsquad/qemu/blob/testing/tcg-tests-revival-v4/tests/tcg/arm/fcvt.c >> >> Some of the ARMv7 versions are commented out as they where not >> supported until later revs. I do have a build that includes that but >> unfortunately the Debian compiler it too old to build it. >> >> : patch 0001/fpu softfloat int_to_float ensure r fully initial.patch needs review >> : patch 0004/target arm convert conversion helpers to fpst ahp.patch needs review >> : patch 0005/target arm squash FZ16 behaviour for conversions.patch needs review > > This still seems to regress the NaN conversion case I mentioned > in review of the previous series: > > (3) Here's a NaN case we get wrong now: 64 to IEEE-16 conversion, > input is 0x7ff0000000000001 (an SNaN), we produce > 0x7c00 (infinity) but should produce 0x7e00 (a QNaN). Hmm I had added the test case but due to another bug it never actually ran :-/ > > thanks > -- PMM -- Alex Bennée