From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) by sourceware.org (Postfix) with ESMTPS id BC8993858D37 for ; Mon, 13 Jul 2020 22:26:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org BC8993858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=andrew@sifive.com Received: by mail-ot1-x341.google.com with SMTP id d4so10965730otk.2 for ; Mon, 13 Jul 2020 15:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Rxr4z8MdnRx1Cus6yz8TYpUOxEvE7hWw16b+PZtfD3g=; b=ITPfGihlnEo3AYGvYo98KTdIrPUuY4E73v12VweOwDoidoUH34tJppyCmLRss9Tx0p Pc19wRK4dO2jZhjTf8ca6dnEHILIrjLvU52PKxoSlagAF3d6u6bfKg5blSkS5QCvsIFO G+9sUfdZaje7X8JrM56FpjeQmrJIFIZnDnDrAjPpLqjKXGVORZ7gI3rg0vqFeKsOB2wE SmSHEEBICQ5Wv2QfkVYVE3SkqiQw2MHhaYcWgsnf5lRty0qvPoclZTKOrP+lqZOcSyAM uY+wC9VOb6EzcgA7UyAlrBxFhckTwrFuHbB6n0JewrR3KuJcrnyIY2CFLOpBeEMEEJqU wvyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Rxr4z8MdnRx1Cus6yz8TYpUOxEvE7hWw16b+PZtfD3g=; b=pHfx20t74ykOqU3zUHcYJAwtPe5noOHAoqTEdiBG40txS7grLbLeLFt/77JW/Dr4BK xK9+nWrEjtNrlmFnYUqnDxqfDeVNCSo2i88ac9mzL2jFmKF8UpYXKVJyCtd8cjSh7d4B XjwN3oPnQHTuyUdqGADScJiZq/PBpqCFL6L56Tyu/X1TsAvoVG3OGsI058O5HpH5q+Dy hINLVJE4DpoPIHLBxuh+65MzYKfLLluicPVmlKALpOMIrDEGI3Y1hfsNi8x5o4MmY9Xz +3KPnw/rK9HaOS3qWu8VqhqK76HDvVBvFKJ07Wfg9l0i9+oI/eZEpeobLZhIR+1yXwj0 cpqg== X-Gm-Message-State: AOAM5316XRfw9dUjIhRJ6oqPuI2zfPoWtmpIqB7pAEwggd2s93eJw91L 7P4H55XG4gN08b7u4vES+ZNE6NNVbBk= X-Google-Smtp-Source: ABdhPJxdyg6Gewj1XH2IRoXPrT8bgj2dSYDa/DO+2MRKi4CXyhlufBTz1chPTT1pB6A3CKvzXb931w== X-Received: by 2002:a05:6830:1d43:: with SMTP id p3mr1605233oth.369.1594679204875; Mon, 13 Jul 2020 15:26:44 -0700 (PDT) Received: from mail-ot1-f43.google.com (mail-ot1-f43.google.com. [209.85.210.43]) by smtp.gmail.com with ESMTPSA id y26sm483294ooq.3.2020.07.13.15.26.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Jul 2020 15:26:44 -0700 (PDT) Received: by mail-ot1-f43.google.com with SMTP id 5so10891983oty.11 for ; Mon, 13 Jul 2020 15:26:43 -0700 (PDT) X-Received: by 2002:a9d:6341:: with SMTP id y1mr1620819otk.338.1594679203687; Mon, 13 Jul 2020 15:26:43 -0700 (PDT) MIME-Version: 1.0 References: <6f6f811cb3453c1de41c8cb542aace23162f90a0.1594568655.git.alistair.francis@wdc.com> <9616c122-ef62-5845-7d13-97577f8c0d57@redhat.com> In-Reply-To: From: Andrew Waterman Date: Mon, 13 Jul 2020 15:26:32 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v3 13/19] RISC-V: Add the RV32 libm-test-ulps To: Joseph Myers Cc: "Carlos O'Donell" , "Maciej W. Rozycki" , libc-alpha@sourceware.org, Alistair Francis Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, 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 22:26:47 -0000 On Mon, Jul 13, 2020 at 2:59 PM Joseph Myers 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