From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from elaine.keithp.com (home.keithp.com [63.227.221.253]) by sourceware.org (Postfix) with ESMTPS id 0EF1B3857C49 for ; Tue, 1 Sep 2020 23:06:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 0EF1B3857C49 Received: from localhost (localhost [127.0.0.1]) by elaine.keithp.com (Postfix) with ESMTP id DC3CA3F2D6D3; Tue, 1 Sep 2020 16:06:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at keithp.com Received: from elaine.keithp.com ([127.0.0.1]) by localhost (elaine.keithp.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MsqcAT29VHGx; Tue, 1 Sep 2020 16:06:08 -0700 (PDT) Received: from keithp.com (koto.keithp.com [10.0.0.2]) by elaine.keithp.com (Postfix) with ESMTPSA id 861993F2D6D2; Tue, 1 Sep 2020 16:06:08 -0700 (PDT) Received: by keithp.com (Postfix, from userid 1000) id 60F5C1582201; Tue, 1 Sep 2020 16:06:08 -0700 (PDT) From: "Keith Packard" To: Joseph Myers Cc: Sebastian Huber , newlib@sourceware.org Subject: Re: [PATCH 0/3] ARM with only 32-bit floats do not have fast 64-bit FMA In-Reply-To: References: <20200808223413.4015633-1-keithp@keithp.com> <1fc07c90-694b-01ea-cedc-0656eccdd827@embedded-brains.de> <87wo1db8kt.fsf@keithp.com> Date: Tue, 01 Sep 2020 16:06:07 -0700 Message-ID: <87lfhtayhs.fsf@keithp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Status: No, score=-5.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, 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: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2020 23:06:14 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Joseph Myers writes: > But note that newlib/libm/common/s_fma.c doesn't actually do anything=20 > useful; it's not a fused operation. Implementing correct fma in software= =20 > is highly nontrivial, especially when you want to handle exceptions and=20 > rounding modes correctly (including machine-specific differences in=20 > whether tininess is detected before or after rounding). Should we just stop providing the generic fma/fmaf implementations? That seems like a good idea to me as it will prevent applications from getting the wrong answer. The fmaf one does offer increased precision by doing the operation in double instead of float, which is 'different' from doing it in float, but it still gets a different answer from 'a * b + c'. It also gets the wrong exception status. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAl9O0+AACgkQ2yIaaQAA ABFKvw/9GHHq2CqhiTvm1++RiGWfqTaHmMseZYF2LnG/DHSMVpJzCrgHnPVv2tYh Nw1MKzJ2lrO0YqOBMtoy9q/VtpwkNgOhjwDcPoZj3Q3FArC6ML01FSRJet1suvLf yTgxozSppalZLbfqSHqDlrl5iprevEafGQyQrEP8NYya8TZ6CYS6KIT26Xdk5D5A HG+IZcXDKPJPSqtoXYsK7cs0/vJbu2BTJ30Ihjwkgx6HuPi1/fk1A7NwddylJ1/f exiRHg04pYpq9Jcjgroy4MVJKBVCEc7jcjB9yRsfCTwJ1k2sSClH4FcF4wg2ZTQS lGrsSmqb814wfzrNckSD+pY3UXIXujyh3CqrwdOHzmSja/Uq1oHaUUg8+FPCahj3 Fy5ZKnKPLpTN2Atwjk7dVtlVDhYIZf6kKjHc7N5MEHpxqQXYeU3hTWMXgTwKjWKb XlbQDWUXQQewAGNuUMWnOZsm3b9H7Q7D9laCPHmkMtUetHO0TdaE94U8yzBdda7b rU+oFO0cgkHVwVbFR2+J/w99XuQdeQL/sQP3aOp8oBff+Tmz3RECBKG45QA+03MK VNZ9QxiWC29jRIxdNnf3eKgNFrlTy1d3CkoDodji5ZG8qG7wjVKTAcHgZ+eqTDol CZqHMHFAifTK+QVBoyYtSRB8b+wI56zL9prGtLqtOJeuFja74Ls= =5Q4Y -----END PGP SIGNATURE----- --=-=-=--