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

[Joseph Myers]

On Mon, 13 Jul 2020, Carlos O'Donell via Libc-alpha wrote:

> > 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?

I believe the semantics of the RISC-V floating-point instructions are 
fully specified (including details such as choice of NaN results) and so 
it's a bug for either hardware or emulator to produce results other than 
those in the architecture specification.

Sometimes architecture specifications do not fully specify results for all 
floating-point instructions.  For example, the Power instructions to 
estimate reciprocal or reciprocal square root have accuracy bounds in the 
architecture specification, but the exact result is not specified, so it 
would be legitimate for hardware and emulation to produce different 
results for those instructions.  But AArch64 has an instruction to 
estimate reciprocal square root whose exact semantics are fully specified 
in the architecture specification, meaning it's a bug if emulation fails 
to produce a result with exactly the same bit-pattern as hardware.  My 
understanding is that all the RISC-V floating-point instructions are fully 
specified, as on AArch64.

-- 
Joseph S. Myers
joseph@codesourcery.com