From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.hgst.iphmx.com (esa3.hgst.iphmx.com [216.71.153.141]) by sourceware.org (Postfix) with ESMTPS id 4B0DA3857C74 for ; Tue, 14 Jul 2020 00:00:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4B0DA3857C74 IronPort-SDR: udpCAP/qrIsvLsKs2/q7NqDYifOhABz35NvbXlDw8A3iBex1l+CgJU16TTbYgRZXjmZTo7Mtto wC/p5Ekl8oq+fE9CX29s21enkaID+OBVt5uLs9R24UCj+MJk6RqU4eQvEYAiFjy+V+g18AyNFQ 2GDdLqgKGOo52/FRnVnTtQf8E9jTz7Ebyx2Lf0AB9yfZY7zXQ6BJzh7IRYrs6VJtXb46Kp0Y3R VnKuCPbpR6IQYl2WoKeK3QktnSxbyUtFhkusvSqKE85CyM8WEHWjuTpnk96gNJXIW5d0q2fSG2 M4E= X-IronPort-AV: E=Sophos;i="5.75,349,1589212800"; d="scan'208";a="146671214" Received: from uls-op-cesaip02.wdc.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 14 Jul 2020 08:00:51 +0800 IronPort-SDR: BCtZPkQA5b3Ag5Csp6ofQhyjTCemUrHhju6wOozkFHJ7K/ArgAnZLifdKCLmoP3pvYUjrnzpKY oRV4Tk7fIW8jEfeKTMOxSXI0eRbpUFdvk= Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2020 16:48:45 -0700 IronPort-SDR: j6/LyJ1ANOEgVlMcIjjOpwm/b057gxr619uvtQ4tlddOSgjwGqu0qY953lbPYNPM+vOT8cgs6p Mt/XPZLy8uAw== WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Jul 2020 17:00:50 -0700 Date: Tue, 14 Jul 2020 01:00:45 +0100 (BST) From: "Maciej W. Rozycki" To: Andrew Waterman cc: Joseph Myers , Carlos O'Donell , libc-alpha@sourceware.org, Alistair Francis Subject: Re: [PATCH v3 13/19] RISC-V: Add the RV32 libm-test-ulps In-Reply-To: Message-ID: References: <6f6f811cb3453c1de41c8cb542aace23162f90a0.1594568655.git.alistair.francis@wdc.com> <9616c122-ef62-5845-7d13-97577f8c0d57@redhat.com> User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 00:00:58 -0000 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