From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 452973860C38 for ; Mon, 13 Jul 2020 21:59:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 452973860C38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: I7g965qUHhQzkAeiPoZE9LvWPYHUcObJI4r1N8rFcx3kGmBfY742jLIiCqqJuk4lFrozz3EHPX 77zRYDx+ceFcVVKO+4BhTp/zKoXB9OD1AgJWqJ19A9VXkH5dH9faPeVXG4z8CqIAXNlXvYCTdz XosQdG+YxYgvYzyoM75ULOdZND/JFfwLVk8mEWgc+3pOG+GBBynQDsJtRtdjp+hKJRVuO6PQfj q46jKOEHoYlxDe/JvcjF4WH7iu54sghVLIThAqJR9dQMQM4jcO3wPzSbhHfu5cTdvXKYU6VMTv p1U= X-IronPort-AV: E=Sophos;i="5.75,348,1589270400"; d="scan'208";a="50998752" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 13 Jul 2020 13:59:26 -0800 IronPort-SDR: 63XEnTsbzHNiM6Z+c3zzcpx5F/T69h5Mww1I6qhDreImLpwosP7pm40b+B6R0xxswXlLTu1TEJ 3/YtuHGryhGh6EDatmUUFu4k74HadG4We4pI6ErT3M7xpjt5hSjXnN1ZA1qeOUGXqXXtcAX8Zy LthMS8ZuQM/fLZ3c8lgs4/ROA8Iw0Fz/4nxHcy2nTs/pv8tnDrj3b0TI5AmqEJUmEBnVG3mt2n FwMdrM419CWhWzBTMF/E8l+qKJy9c34SFXy/2c2w6cZEHuDPwb5jWscj9wrw18izLV/69i4prd f/U= Date: Mon, 13 Jul 2020 21:59:20 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Carlos O'Donell CC: "Maciej W. Rozycki" , Alistair Francis , Subject: Re: [PATCH v3 13/19] RISC-V: Add the RV32 libm-test-ulps In-Reply-To: <9616c122-ef62-5845-7d13-97577f8c0d57@redhat.com> Message-ID: References: <6f6f811cb3453c1de41c8cb542aace23162f90a0.1594568655.git.alistair.francis@wdc.com> <9616c122-ef62-5845-7d13-97577f8c0d57@redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3129.2 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, 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: Mon, 13 Jul 2020 21:59:37 -0000 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