From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) by sourceware.org (Postfix) with ESMTPS id 5A00F3858D39 for ; Wed, 31 Aug 2022 15:22:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5A00F3858D39 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x1029.google.com with SMTP id i7-20020a17090adc0700b001fd7ccbec3cso3867533pjv.0 for ; Wed, 31 Aug 2022 08:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=u+Wjkh0iaT0BrVFLbNhjCFBw7nTIJNgcV4FeLJXX3mg=; b=WbAtgx2hKgOTwnzEg5Nj7MxOmpiWqGrM9ZY2+hfUbJc7my08sjG20sJnGcdw9qKFCz ZUDQ4UYsa1bR55//2c1UiFei1Pcgf4vpAYn54am+GrBleFk1R0pwpgopDn/mFzJk1kkD BiYootjaI0yDSXCKsGDwncooak8aLxexUQZ8IfSxdigOXImmfqifTGO1yNx9jO3e1g8w Tn7tsdtLHcKsMYgpAOoTu9J73r0JWisFGu1KmaPXipgDWQgrDCp9jiYQYXQbH/eRnt4Y UHmB3b1YI+l/H3tXXjE8rzL1Cz2g5BlHnhaywkzOHGsyTJ3+fgEBt4TE/VfY11UyaMIv W9+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=u+Wjkh0iaT0BrVFLbNhjCFBw7nTIJNgcV4FeLJXX3mg=; b=0eHXLpD5NWY47Qaw8qaUfRTYElY0l7RtE2u/GxlXgApIL8cYdwu2kqi3nSBotrGTLf E8QNFCFdAkrp6ArXAkLuA1ByIIJbLfTjcyAfPSU7TLEK/XAm0LX/kKbfcwOZw+VAdqmG GAx6ngPPgTxaEwOZ4sb/OpYD1TeQKiQf6SsY4+6oe63FbiXy/v63y9AnmlBYHqGjpi6d 6nL/WvxU7VizqoBuTzxCVedJpeap5A80Br0nlWqQzzphLWr58gx4cgbyB0RZ/uxs1IGF ktbPc1nHVvIPqCK9KNTT7k572Go2T/I8on2/i5ofSqVrIBCPU7OI7RzqPGy3ApS3y4zG aoEQ== X-Gm-Message-State: ACgBeo29HoeUbrIAGMgIVhCCETNYuaxAz8DkXJnKm/saqMnvDAzVNJY6 8+e900/aTkE3dfHfzJXWaEXRLLACBrc= X-Google-Smtp-Source: AA6agR5CQAzOG+HAVtYi41utYeatf1MUpUxv8FBDPvTWXMuAqZuFd4hGvkuapZYAJK4bKTyzB8fBMg== X-Received: by 2002:a17:902:8e83:b0:173:28b:3616 with SMTP id bg3-20020a1709028e8300b00173028b3616mr26357693plb.149.1661959346813; Wed, 31 Aug 2022 08:22:26 -0700 (PDT) Received: from [172.31.0.204] (c-73-98-188-51.hsd1.ut.comcast.net. [73.98.188.51]) by smtp.gmail.com with ESMTPSA id x12-20020a63f70c000000b0041b2f37c571sm3427130pgh.34.2022.08.31.08.22.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 31 Aug 2022 08:22:26 -0700 (PDT) Message-ID: <970dc764-07e0-b57f-30c8-f14e059d3d80@gmail.com> Date: Wed, 31 Aug 2022 09:22:25 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0 Subject: Re: [PATCH] Add support for floating point endpoints to frange. Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <20220823114224.904934-1-aldyh@redhat.com> <36232923-497e-0de4-414f-41c1b33fbb30@moene.org> From: Jeff Law In-Reply-To: <36232923-497e-0de4-414f-41c1b33fbb30@moene.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham 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/2022 8:42 AM, Toon Moene wrote: > 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. Agreed. Jeff