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 31C70395C834 for ; Wed, 11 Mar 2020 22:41:19 +0000 (GMT) Received: from localhost (localhost [127.0.0.1]) by elaine.keithp.com (Postfix) with ESMTP id 393533F2B425; Wed, 11 Mar 2020 15:41:18 -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 OFdW4RWYyuiV; Wed, 11 Mar 2020 15:41:17 -0700 (PDT) Received: from keithp.com (koto.keithp.com [10.0.0.2]) by elaine.keithp.com (Postfix) with ESMTPSA id 7F81E3F2B424; Wed, 11 Mar 2020 15:41:17 -0700 (PDT) Received: by keithp.com (Postfix, from userid 1000) id 5BF1F1582127; Wed, 11 Mar 2020 15:41:17 -0700 (PDT) From: "Keith Packard" To: Joseph Myers Cc: Fabian Schriever , newlib@sourceware.org Subject: Re: [PATCH] Fix truncf for sNaN input In-Reply-To: References: <20200311095805.582-1-fabian.schriever@gtd-gmbh.de> <87zhcmr52d.fsf@keithp.com> Date: Wed, 11 Mar 2020 15:41:16 -0700 Message-ID: <87sgieqzub.fsf@keithp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Spam-Status: No, score=-2.1 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 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: Wed, 11 Mar 2020 22:41:19 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Joseph Myers writes: > That manpage is wrong. The underlying IEEE operation should raise=20 > "invalid" and return a qNaN for an sNaN operand (but never raises=20 > "inexact"). Hrm. IEEE 754 says that you only get "invalid" if the NaN or infinite operand cannot be represented in the destination format. As these functions return the same type as their operand, NaN and inf values can be represented in the return value. Are you referring to some other standard? Also, glibc works the way the manual says, and I'd really like newlib and glibc to have the same general behavior, even if newlib isn't quite as accurate as glibc for some operations. =2D-=20 =2Dkeith --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEw4O3eCVWE9/bQJ2R2yIaaQAAABEFAl5paQ0ACgkQ2yIaaQAA ABHqZw//b5aCxncOwZRG3dLFr2WSxPT/oHQZltRltWDCTAi5HKttSnAaHmVs6d3p NIrH1I4P8x+ETEJZ+G9su04Qz/43qMsvAg+jIcuu8Cta7ea2hpza2JwyfoLKPouR /so/o6iKv5CsyqQRZVbLvOF+174ufBFDVoEZJSQ1wyHgLu9rAuJqXUxHGA1n3lV2 CTqn41n/r0l760nrVgYJ0di1Qi768QdLyD550RN3dAuVBW8DyUTuAFz6q19Y7/2+ 3RpYjZvcPQ6HuRT8n79bLDNt2GmlUlRDX0rtNrkyr1iyxL8qTRXl7JlrcjnGRLFE ejo/RAbbf7NU23OR3EVEB6ak4R0zf2wdr25YXmUNSzwmBnDUBwdd24+a4xraDS8X gBzk8cjcSRF5kC2grMEwUbCEOxjo11UCIv12lJPl+uNRD3FGFXbYqHgoC+H8Or9L qhKpHfrDS8C3kt+z4MD5/8qqyR1/sgFQYPM6vtbk6gRP+oEUm2Nacq3jhYKWz6fS Mrw6+Apm28ygFMR2Rs3bLhHwVsTZKTZ0YRQZgCtB6kpyeA8BlUE7HuHcamG1s9Ab 3MDIH4oItTlBMp8DEb5y4ZodTl0VVzlk0yXgSxZYuPogIYt6MtFyMNU/Qs42mBmW 9pdQA7v9cbKR8/ijF1kBdsqAyYgvs3XhHK9eQkQ4Pw0qhCjE/Pg= =Avl5 -----END PGP SIGNATURE----- --=-=-=--