From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gtd-gmbh.de (mail.gtd.eu [46.24.46.35]) by sourceware.org (Postfix) with ESMTPS id 62ABA385E82C for ; Tue, 17 Mar 2020 15:27:30 +0000 (GMT) X-MDAV-Result: clean X-MDAV-Processed: gtd-gmbh.de, Tue, 17 Mar 2020 16:26:12 +0100 Received: by gtd-gmbh.de (MDaemon PRO v19.5.4) with ESMTPSA id md50013616976.msg; Tue, 17 Mar 2020 16:26:11 +0100 X-Spam-Processed: gtd-gmbh.de, Tue, 17 Mar 2020 16:26:11 +0100 (not processed: message from trusted or authenticated source) X-MDRemoteIP: 78.42.121.247 X-MDArrival-Date: Tue, 17 Mar 2020 16:26:11 +0100 X-Authenticated-Sender: fabian.schriever@gtd-gmbh.de X-Return-Path: prvs=1345bad6eb=fabian.schriever@gtd-gmbh.de X-Envelope-From: fabian.schriever@gtd-gmbh.de X-MDaemon-Deliver-To: newlib@sourceware.org Subject: Re: [PATCH] Fix truncf for sNaN input To: Joseph Myers , Keith Packard Cc: newlib@sourceware.org References: <20200311095805.582-1-fabian.schriever@gtd-gmbh.de> <87zhcmr52d.fsf@keithp.com> <87sgieqzub.fsf@keithp.com> <87wo7km63l.fsf@keithp.com> From: Fabian Schriever Message-ID: <794619dc-3dc7-9391-10bd-0ce5eaa4f19b@gtd-gmbh.de> Date: Tue, 17 Mar 2020 16:26:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: X-Spam-Status: No, score=1.1 required=5.0 tests=HTML_MESSAGE, HTML_OBFUSCATE_10_20, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_NONE autolearn=no autolearn_force=no version=3.4.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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, 17 Mar 2020 15:27:32 -0000 Am 17/03/2020 um 02:30 schrieb Joseph Myers: > On Mon, 16 Mar 2020, Keith Packard via Newlib wrote: > >> 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 don't think POSIX specifications should be trusted for how functions > should behave with sNaN inputs. Rather, prefer the specifications from TS > 18661-1 (or the latest C2x draft which has TS 18661-1 integrated). > I agree that both the IEEE-754 and C standards should take precedence over POSIX, nonetheless POSIX does contain a chapter on the treatment of NaNs including signaling NaNs: §4.20 (I only have access to the POSIX draft 3 from 2007: http://www.open-std.org/jtc1/sc22/open/n4217.pdf). It contains the following: On implementations that support the IEC60559: 1989 standard floating point, functions with signaling NaN argument(s) shall be treated as if the function were called with an argument that is a required domain error and shall return a quiet NaN result, except where stated otherwise. Note:    The function might never see the signaling NaN, since it might trigger when the arguments are evaluated during the function call. On implementations that support the IEC60559: 1989standard floating point, for those functions that do not have a documented domain error, the following shall apply:     These functions shall fail if:     Domain Error   Any argument is a signaling NaN.     Either, the integer expression (math_errhandling & MATH_ERRNO) is non-zero and errno shall be set to [EDOM], or the integer expression (math_errhandling &MATH_ERREXCEPT) is non-zeroand the invalid floating-point exception shall be raised. For this change I only sought to have the single-precision function perform the same as it's double counterpart for now. I have not checked whether the POSIX requirements regarding errno are met.