From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from moene.org (84-86-97-173.fixed.kpn.net [84.86.97.173]) by sourceware.org (Postfix) with ESMTPS id 85D5D3858D32 for ; Mon, 29 Aug 2022 14:42:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 85D5D3858D32 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=moene.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=moene.org Received: from localhost ([127.0.0.1]) by moene.org with esmtp (Exim 4.96) (envelope-from ) id 1oSfxj-00B2Xi-1m; Mon, 29 Aug 2022 16:42:03 +0200 Message-ID: <36232923-497e-0de4-414f-41c1b33fbb30@moene.org> Date: Mon, 29 Aug 2022 16:42:03 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.1.2 Subject: Re: [PATCH] Add support for floating point endpoints to frange. Content-Language: en-US To: Aldy Hernandez , Jakub Jelinek Cc: gcc-patches References: <20220823114224.904934-1-aldyh@redhat.com> From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KHOP_HELO_FCRDNS,NICE_REPLY_A,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 8/29/22 16:36, Aldy Hernandez wrote: > On Mon, Aug 29, 2022 at 4:30 PM Toon Moene wrote: >> >> On 8/29/22 16:15, Aldy Hernandez wrote: >> >>> But even with -ffinite-math-only, is there any benefit to propagating >>> a known NAN? For example: >> >> The original intent (in 2002) for the option -ffinite-math-only was for >> the optimizers to ignore all the various exceptions to common >> optimizations because they might not work correctly when presented with >> a NaN or an Inf. >> >> I do not know what the effect for floating point range information would >> be - offhand. >> >> But in the *spirit* of this option would be to ignore that the range >> [5.0, 5.0] would "also" contain NaN, for instance. > > Hmm, this is somewhat similar to what Jakub suggested. Perhaps we > could categorically set !NAN for !HONOR_NANS at frange construction > time? > > For reference: > bool > HONOR_NANS (machine_mode m) > { > return MODE_HAS_NANS (m) && !flag_finite_math_only; > } > > Thanks. > Aldy > Yep, I think that would do it. Thanks, -- Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands