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 5E6AC396E45A for ; Wed, 11 Mar 2020 23:14:49 +0000 (GMT) IronPort-SDR: KEpzkI6ZQ92v+9Wnv1/KSwrwFnjda338KZ+gnXhiyY9SXgVfxj466Bn2mTUYU7wBWMC0tO7heo UAUG5Qj1ynMePqfcMT8mXyY1mWNUAF/PifAfr7kbZQ09Kn1K6tN7YyjjIdhexkSmTMezNcbyau vxzhZ3NrtAre4Qc1zgb92DmzUo1Mijjfx4lKTlO5HMM1z8oX/Sk/aeSgMNR5XJ6CcvG1Zb2YNR gCXxhDUX1aWXi20Vu6E2wPXeFceb2cLLx6H4KKH7PwpK5N/l1taJCthmecPBB6h0OAqyHJwB31 x+Q= X-IronPort-AV: E=Sophos;i="5.70,542,1574150400"; d="scan'208";a="46676458" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 11 Mar 2020 15:14:48 -0800 IronPort-SDR: SwiG8HfognWXlTxUVnb/ODKVKskmqDGytv/z2KSfxBM4z/iyGNerfL0UWfbP81PvWsz9wBQ5OK zwkQhywW6BzrFqZzjeTXcZbbq8196bi3W5FOWN9WM7Jf91aUd/5oe+Nbfpwp3RqoM98IKO1dnG +YMAJq2QL2kC01amzsnaHhHAWy2B8M44aZ9pyURpSO0YQJ5oOBgkv537DhD8rReWI7Oi6IDmkw JgiBldjZjvPrhG2C2F/ITjcKac3T2EXDkbUcail78+SGAWFDoV3LPoJ+vMc/e2SRyaoilegMdq /xg= Date: Wed, 11 Mar 2020 23:14:42 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: Keith Packard CC: , Fabian Schriever Subject: Re: [PATCH] Fix truncf for sNaN input In-Reply-To: <87sgieqzub.fsf@keithp.com> Message-ID: References: <20200311095805.582-1-fabian.schriever@gtd-gmbh.de> <87zhcmr52d.fsf@keithp.com> <87sgieqzub.fsf@keithp.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-02.mgc.mentorg.com (139.181.222.2) To SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, SPF_HELO_NONE, SPF_PASS autolearn=no 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 23:14:50 -0000 On Wed, 11 Mar 2020, Keith Packard via Newlib wrote: > Joseph Myers writes: > > > That manpage is wrong. The underlying IEEE operation should raise > > "invalid" and return a qNaN for an sNaN operand (but never raises > > "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? I'm referring to 6.2 Operations with NaNs, "Signaling NaNs shall be reserved operands that signal the invalid operation exception (see 7.2) for every general-computational and signaling-computational operation except for the conversions described in 5.12.". > 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. glibc's libm-test-trunc.inc explicitly verifies that sNaN inputs to trunc functions result in a qNaN output with "invalid" but not "inexact" raised. -- Joseph S. Myers joseph@codesourcery.com