On Wed, 7 Mar 2018 at 11:11 PM, Richard W.M. Jones <rjo...@redhat.com> 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