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 1CE593871029 for ; Mon, 16 Mar 2020 19:50:57 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by elaine.keithp.com (Postfix) with ESMTP id 9F5D13F29DDE; Mon, 16 Mar 2020 12:50:55 -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 USPWvHBtVvcU; Mon, 16 Mar 2020 12:50:55 -0700 (PDT) Received: from keithp.com (koto.keithp.com [10.0.0.2]) by elaine.keithp.com (Postfix) with ESMTPSA id 285523F206B1; Mon, 16 Mar 2020 12:50:55 -0700 (PDT) Received: by keithp.com (Postfix, from userid 1000) id EC6C01582127; Mon, 16 Mar 2020 12:50:54 -0700 (PDT) From: "Keith Packard" To: Joseph Myers Cc: newlib@sourceware.org, Fabian Schriever Subject: Re: [PATCH] Fix truncf for sNaN input In-Reply-To: References: <20200311095805.582-1-fabian.schriever@gtd-gmbh.de> <87zhcmr52d.fsf@keithp.com> <87sgieqzub.fsf@keithp.com> Date: Mon, 16 Mar 2020 12:50:54 -0700 Message-ID: <87wo7km63l.fsf@keithp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Status: No, score=-0.2 required=5.0 tests=DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS 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: Mon, 16 Mar 2020 19:50:58 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Joseph Myers writes: > I'm referring to 6.2 Operations with NaNs, "Signaling NaNs shall be=20 > reserved operands that signal the invalid operation exception (see 7.2)=20 > for every general-computational and signaling-computational operation=20 > except for the conversions described in 5.12.". I believe you are concerned with the exception behavior, where the original code was wrong. Section 5.9 says that conversion functions signal for sNaN input, while 6.2 says that they deliver a qNaN result. I was concerned with what NaN values are delivered from a NaN operand, given the POSIX specification which says that the operand itself shall be delivered if it is a NaN. I hadn't considered the exception behavior, nor had I realized that sNaN operands cause a qNaN to be delivered. I need to interpret the POSIX spec as saying that a NaN operand will deliver *some* NaN, but not that it will deliver the NaN operand. The functions cannot do this in the case of sNaN operands which must deliver a qNaN according to the IEEE spec. I'll update the newlib tests to verify that sNaN parameters deliver qNaN results, and to allow any qNaN value for a qNaN operand, instead of requiring that the functions return precisely the same qNaN value. Those tests don't currently encode the signal behavior; I'll have to add support for that at some point. Thanks much for your clarifications and pointers to the relevant specs. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAl5v2J4ACgkQ2yIaaQAA ABEZWBAAo86IYFFVKrGtkhAAWpj5uf8rC12QkFWFlcl/lRJxCPaG+8EVM5fHmljc ZKq6SgaGwIUZ4Efyh2Fq+6w9dsapTWqsQY+053/Ip5KDnMr4CMyepzB+5sxGhCm1 5xDSRgfKRRsx+T+WbccJXUMw8hlRXekwywSqjGYCYofdSk4GChaeYAtnGOs/Z87k z75N8YTZTop7SX63NjTXn+FxM/3fuVx/aT8FpVPs/0b8axOSMmrYRXaucBymOuOA ULiSPO+MaeVy5MHa/YHMRVCPUj881J1+OaOdXRWaKegmiLGjIIn+Xq2fcwpFN4K4 nVOOAcKY5mLtO2NM65lpcrwSIvZLD/QBZOZKBdfbMA1NokThvKODTvE0BMIZRV78 jrpC4V/wuBAqjVOOhsoRChubEhJiMbQgpoTvF2GM4oBdtq+XmejreznrH2D1J2ea uTN+cabuSih/qoj9Ah08y4OrUp96CGp141TtRGFXLDjZzv5xrvx4FxzMz3vGNddD dkO7iu2gNbrKNVTftmi/CtREIB19qxXpByakSsK7pznIlBdbFFyT7Kq9qGue9JPZ FSq56Ae4pkN0biG4fWsgRAQsJG4WtchPSQq5TE99sIlQcgO1p16cC6w1pg2G0cUm BHQErBa3w3ikeNxfqe2Pqnnzockiz9ZSRbwBVWT07r448/vzd3s= =7Y4G -----END PGP SIGNATURE----- --=-=-=--