From: Andrew Waterman <andrew@sifive.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: "Carlos O'Donell" <carlos@redhat.com>,
"Maciej W. Rozycki" <macro@wdc.com>,
libc-alpha@sourceware.org,
Alistair Francis <alistair.francis@wdc.com>
Subject: Re: [PATCH v3 13/19] RISC-V: Add the RV32 libm-test-ulps
Date: Mon, 13 Jul 2020 15:26:32 -0700 [thread overview]
Message-ID: <CA++6G0BGL4EQV_=nuD=Y=BSAPEciXMF9Rr0sJTbmGCZ6J8PT0Q@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2007132152060.20292@digraph.polyomino.org.uk>
On Mon, Jul 13, 2020 at 2:59 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> 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.
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.
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
next prev parent reply other threads:[~2020-07-13 22:26 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-12 15:47 [PATCH v3 00/19] glibc port for 32-bit RISC-V (RV32) Alistair Francis
2020-07-12 15:47 ` [PATCH v3 01/19] RISC-V: Use 64-bit time_t and off_t for RV32 and RV64 Alistair Francis
2020-07-15 17:29 ` Maciej W. Rozycki
2020-07-12 15:47 ` [PATCH v3 02/19] RISC-V: Cleanup some of the sysdep.h code Alistair Francis
2020-07-16 1:07 ` Maciej W. Rozycki
2020-08-10 15:16 ` Alistair Francis
2020-07-12 15:47 ` [PATCH v3 03/19] RISC-V: Use 64-bit-time syscall numbers with the 32-bit port Alistair Francis
2020-07-16 1:58 ` Maciej W. Rozycki
2020-08-10 15:15 ` Alistair Francis
2020-07-12 15:47 ` [PATCH v3 04/19] RISC-V: Add support for 32-bit vDSO calls Alistair Francis
2020-07-16 0:12 ` Maciej W. Rozycki
2020-07-12 15:47 ` [PATCH v3 05/19] RISC-V: Support dynamic loader for the 32-bit Alistair Francis
2020-07-12 15:47 ` [PATCH v3 06/19] sysv/linux: riscv: Fix dl-cache.h indentation Alistair Francis
2020-07-16 6:31 ` Maciej W. Rozycki
2020-07-12 15:47 ` [PATCH v3 07/19] RISC-V: Add path of library directories for the 32-bit Alistair Francis
2020-07-16 7:03 ` Maciej W. Rozycki
2020-07-12 15:47 ` [PATCH v3 08/19] RISC-V: Add arch-syscall.h for RV32 Alistair Francis
2020-07-12 15:47 ` [PATCH v3 09/19] RISC-V: nptl: update default pthread-offsets.h Alistair Francis
2020-07-12 15:47 ` [PATCH v3 10/19] RISC-V: Support the 32-bit ABI implementation Alistair Francis
2020-07-16 8:23 ` Maciej W. Rozycki
2020-07-12 15:47 ` [PATCH v3 11/19] RISC-V: Hard float support for 32-bit Alistair Francis
2020-07-16 8:27 ` Maciej W. Rozycki
2020-07-12 15:47 ` [PATCH v3 12/19] RISC-V: Add ABI lists Alistair Francis
2020-07-12 15:47 ` [PATCH v3 13/19] RISC-V: Add the RV32 libm-test-ulps Alistair Francis
2020-07-13 17:14 ` Maciej W. Rozycki
2020-07-13 17:32 ` Alistair Francis
2020-07-13 19:19 ` Maciej W. Rozycki
2020-07-13 19:38 ` Carlos O'Donell
2020-07-30 23:11 ` [PATCH] RISC-V: Update lp64d libm-test-ulps according to HiFive Unleashed Maciej W. Rozycki
2020-08-03 17:52 ` Carlos O'Donell
2020-08-04 12:01 ` Maciej W. Rozycki
2020-07-13 21:26 ` [PATCH v3 13/19] RISC-V: Add the RV32 libm-test-ulps Joseph Myers
2020-07-13 21:30 ` Carlos O'Donell
2020-07-13 21:59 ` Joseph Myers
2020-07-13 22:26 ` Andrew Waterman [this message]
2020-07-14 0:00 ` Maciej W. Rozycki
2020-07-14 17:24 ` Joseph Myers
2020-07-12 15:47 ` [PATCH v3 14/19] RISC-V: Fix llrint and llround missing exceptions on RV32 Alistair Francis
2020-07-14 22:13 ` Maciej W. Rozycki
2020-07-22 16:30 ` Alistair Francis
2020-07-12 15:48 ` [PATCH v3 15/19] RISC-V: Build Infastructure for 32-bit Alistair Francis
2020-07-14 23:55 ` Maciej W. Rozycki
2020-08-10 15:45 ` Alistair Francis
2020-07-12 15:48 ` [PATCH v3 16/19] riscv32: Specify the arch_minimum_kernel as 5.4 Alistair Francis
2020-07-15 0:06 ` Maciej W. Rozycki
2020-07-16 1:34 ` Maciej W. Rozycki
2020-07-12 15:48 ` [PATCH v3 17/19] RISC-V: Add rv32 path to RTLDLIST in ldd Alistair Francis
2020-07-15 0:32 ` Maciej W. Rozycki
2020-08-10 20:04 ` Alistair Francis
2020-07-12 15:48 ` [PATCH v3 18/19] Documentation for the RISC-V 32-bit port Alistair Francis
2020-07-13 17:17 ` Adhemerval Zanella
2020-07-14 13:28 ` Alistair Francis
2020-07-15 0:53 ` Maciej W. Rozycki
2020-07-22 16:33 ` Alistair Francis
2020-07-12 15:48 ` [PATCH v3 19/19] Add RISC-V 32-bit target to build-many-glibcs.py Alistair Francis
2020-07-15 1:16 ` Maciej W. Rozycki
2020-07-13 21:15 ` [PATCH v3 00/19] glibc port for 32-bit RISC-V (RV32) Joseph Myers
2020-07-14 13:18 ` Alistair Francis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA++6G0BGL4EQV_=nuD=Y=BSAPEciXMF9Rr0sJTbmGCZ6J8PT0Q@mail.gmail.com' \
--to=andrew@sifive.com \
--cc=alistair.francis@wdc.com \
--cc=carlos@redhat.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=macro@wdc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).