[PATCH v3 13/19] RISC-V: Add the RV32 libm-test-ulps

[Carlos O'Donell]

On 7/13/20 5:26 PM, Joseph Myers wrote:
> On Mon, 13 Jul 2020, Maciej W. Rozycki via Libc-alpha wrote:
> 
>> On Sun, 12 Jul 2020, Alistair Francis via Libc-alpha wrote:
>>
>>> Add a libm-test-ulps for RV32, this is the same as the RV64 one.
>>>
>>> This dosn't match what is generated by running `make regen-ulps` on RV32
>>> QEMU, but the current in tree RV64 doesn't match that either.
>>
>>  For the record RV32 and RV64 QEMU ULPS results (obtained in the Linux 
>> user emulation mode) match each other in my setup.  However those don't 
>> match RV64 results obtained with my HiFive Unleashed hardware, and then 
>> those don't match our existing RV64 results, so I guess they will have to 
>> be regenerated for the upcoming release.
> 
> If results on QEMU and on hardware (for the same binaries) don't match, 
> that indicates a bug in one or the other, which you could find by 
> identifying the exact instruction at which different floating-point values 
> first appear.  (You can get different results from compilation with 
> different options or compiler versions, however, without any such bug, 
> because of e.g. changes in when the compiler chose to contract an 
> expression to use fused multiply-add.)

Is it really a "bug?" QEMU as an emulator could be taking liberties that
the hardware does not for the express purpose of improving emulated
performance? Is it ever QEMU's contract that it will operate identically
to hardware given the same software configuration?

-- 
Cheers,
Carlos.