Re: [Qemu-devel] [PULL] RISC-V QEMU Port Submission v8.2

[Michael Clark]

On Wed, 7 Mar 2018 at 11:11 PM, Richard W.M. Jones <address@hidden>
wrote:

> On Wed, Mar 07, 2018 at 01:09:29PM +1300, Michael Clark wrote:
> > Hopefully, this PR gets merged...
>
> I hope so too.  We've been testing v8 (substantially the same as v8.2)
> extensively, including SMP.  It's building hundreds of packages a day
> in the autobuilder, and being used for manual builds by several
> people.
>
> Please don't forget about the softfloat fix!  Although it's not
> specific to riscv-qemu, it is required for reliable operation and I
> don't see if in the v8.2 tree.


I’ll try to get it in. I’ve reviewed the new minmax code and it should not
be difficult to add IEEE-754 201x minimumNumber/maximumNumber. I just ran
out of time today.

It’s a relatively rare corner case where the RISC-V behaviour is different
when an sNaN operand and a valid operand are provided to fmin/fmax. The
IEEE-754 201x minimumNumber/maximumNumber always returns the valid operand
when passed anyNaN and a valid operand however an sNaN operand causes the
invalid flag to be raised, whereas iirc the IEEE-764 2008 minNum/maxNum
will raise the invalid flag and return the sNaN when one operand is an sNaN
and the other is valid. Both of their behaviours are the same when passed
qNaN and a valid operand.

I have the test suite which includes both signalling and quiet NaN
fmin/fmax test cases so it is easy to verify and RISC-V is the only QEMU
port to use the IEEE-754 201x  minimumNumber/maximumNumber semantics so we
can easily isolate and test the change without affecting existing code.

Michael