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

[Maciej W. Rozycki]

On Mon, 13 Jul 2020, Andrew Waterman wrote:

> > 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.
> 
> This is indeed the case (at least for now; the forthcoming vector
> extension adds an unordered sum reduction whose result can vary by
> implementation).  I think it would be good to confirm whether the
> exact same binaries were used for the QEMU and Unleashed experiments,
> and if not, whether the disparity remains when that's rectified.

 Well, yes.  I just ran `make regen-ulps' consecutively with different 
`test-wrapper*' variables each time so as to redirect execution either to 
my HiFive Unleashed board or (user-mode) QEMU.  I have double-checked the 
logs now and no rebuild was made for subsequent runs, so the very same 
executables and DSOs were used.

 I tend to trust hardware with these matters and only use QEMU for quick 
comparative verification where hardware is slow, or where hardware is 
unavailable.  A silicon erratum cannot be excluded in this case of course, 
but I would check QEMU first.

  Maciej