Re: [Qemu-devel] [PATCH] FMULX should flushes operators to zero when FZ is set.

Peter Maydell writes: > On 28 January 2015 at 15:57, Peter Maydell wrote: >> On 28 January 2015 at 15:54, Alex Bennée wrote: >>> Do we have test cases that trip up here? It would be nice to include >>> them in our testing as the random nature of RISU has obviously failed to >>> trip up on this

Re: [Qemu-devel] [PATCH] FMULX should flushes operators to zero when FZ is set.

On 28 January 2015 at 15:57, Peter Maydell wrote: > On 28 January 2015 at 15:54, Alex Bennée wrote: >> Do we have test cases that trip up here? It would be nice to include >> them in our testing as the random nature of RISU has obviously failed to >> trip up on this instruction. > > Risu would pr

Re: [Qemu-devel] [PATCH] FMULX should flushes operators to zero when FZ is set.

On 28 January 2015 at 16:12, Claudio Fontana wrote: > If nobody improved it from my implementation, the risugen script > will generate code which sets FPSR always unconditionally to 0, > while the FPCR is wired up with the user-provided "fpscr" option. > Not that there's any good reason behind it,

Re: [Qemu-devel] [PATCH] FMULX should flushes operators to zero when FZ is set.

Hi Peter, On 28.01.2015 16:57, Peter Maydell wrote: > On 28 January 2015 at 15:54, Alex Bennée wrote: >> Do we have test cases that trip up here? It would be nice to include >> them in our testing as the random nature of RISU has obviously failed to >> trip up on this instruction. > > Risu would

Re: [Qemu-devel] [PATCH] FMULX should flushes operators to zero when FZ is set.

If RISU sets random FPSCR (FZ bit) values, I think such cases would be covered; it doesn’t look like such a corner case. Maybe I can include some focus tests on this scenario if RISU failed to generate this pattern? Thanks - xiangyu > On 28 Jan, 2015, at 11:57 pm, Peter Maydell wrote: > >

Re: [Qemu-devel] [PATCH] FMULX should flushes operators to zero when FZ is set.

Xiangyu Hu writes: > The difference between FMULX and FMUL is that FMULX will return 2.0f when one > operator is > FPInfinity and the other one is FPZero, whilst FMUL will return a Default > NaN. Without > this patch, the emulation would result in inconsistency. > > Signed-off-by: Xiangyu Hu

Re: [Qemu-devel] [PATCH] FMULX should flushes operators to zero when FZ is set.

On 28 January 2015 at 15:54, Alex Bennée wrote: > Do we have test cases that trip up here? It would be nice to include > them in our testing as the random nature of RISU has obviously failed to > trip up on this instruction. Risu would probably catch this if we generated and ran test cases which

Re: [Qemu-devel] [PATCH] FMULX should flushes operators to zero when FZ is set.

Thanks Peter. I have sent another patch with updated commit message. - xiangyu > On 28 Jan, 2015, at 10:54 pm, Peter Maydell wrote: > > On 28 January 2015 at 14:51, Xiangyu Hu > wrote: >> The difference between FMULX and FMUL is that FMULX will return 2.0f when >>

[Qemu-devel] [PATCH] FMULX should flushes operators to zero when FZ is set.

The difference between FMULX and FMUL is that FMULX will return 2.0f when one operator is FPInfinity and the other one is FPZero, whilst FMUL will return a Default NaN. Without this patch, the emulation would result in inconsistency. Signed-off-by: Xiangyu Hu --- target-arm/helper-a64.c | 6

Re: [Qemu-devel] [PATCH] FMULX should flushes operators to zero when FZ is set.

On 28 January 2015 at 14:51, Xiangyu Hu wrote: > The difference between FMULX and FMUL is that FMULX will return 2.0f when one > operator is > FPInfinity and the other one is FPZero, whilst FMUL will return a Default > NaN. Without > this patch, the emulation would result in inconsistency. > > S