From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id F2CC73858D37 for ; Mon, 29 Aug 2022 14:15:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F2CC73858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1661782550; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=lmM+xqfI85sGN7t/D+/amuhe28GxM5kVa5v4TZQFg7k=; b=eEw+Uag9eObWr3z0EZEJH08SeBvzQzt8hmAnfl416FBZ8DkLILR52Sr+RVtLBNP5w1IZAs Rd9Tj5/u8A4eiQHkWbYQQCjEpHqBal0GEE45ldFR8MHzdwrUBM2PCntA81nNj0o6MkyfXK X1U4ZJNFGmHnun59nj9KiSbB1iQGcuQ= Received: from mail-oi1-f197.google.com (mail-oi1-f197.google.com [209.85.167.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-643-pUcRJ40MPuK_LYM9eUsK8g-1; Mon, 29 Aug 2022 10:15:46 -0400 X-MC-Unique: pUcRJ40MPuK_LYM9eUsK8g-1 Received: by mail-oi1-f197.google.com with SMTP id p125-20020acaf183000000b003457457c168so2563975oih.2 for ; Mon, 29 Aug 2022 07:15:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=lmM+xqfI85sGN7t/D+/amuhe28GxM5kVa5v4TZQFg7k=; b=T1WUYu/2DitMZ16xus6c98KnxESQm4C9wTz8BD0jBRySo758BbVrisvvjhHpdErlQn BjDGTFivQlphxM2irAZAnpW3teGXOGwPJYM/IXN717HxrKiPK1IorbyHjc3jR5E86zWb qMA1gneUjVXRGW8LuYbmRm5eNGHoZ75j6IL0lxIogOysE9bb7ct+vszOkFSYigyNu/9v XkmfhX2ILUbysfinC+mvJCmXxzqLkt4sU1Uk8DfyEn9glaOtMljEucjOryNc2ljSeM6/ fwMLehlZe2q/xmHkyg+UjEDzxJScgMVSwbFaBQYoSBRELC+GVHTD5qa2Muwl8xBE4HwU xH0Q== X-Gm-Message-State: ACgBeo3MJa2TPUspQ1yoIyX8kqkjGlDM0dYdM3ylYiovy+X1noQBC1ey 7dsQdcoUDn2vaKO6wi/PuV/kcU1TAWPDNncoQ9FSO6uHNsxjujX80a3cTOeVXRHYZykwbHNNwxH jbAjhaSBwrpvGuDajAdBcrOY9xfGFkA+dig== X-Received: by 2002:a05:6830:448c:b0:638:96f5:a077 with SMTP id r12-20020a056830448c00b0063896f5a077mr6785471otv.335.1661782545882; Mon, 29 Aug 2022 07:15:45 -0700 (PDT) X-Google-Smtp-Source: AA6agR5P/ZBFgxDlD+tRU+fouFosHR3KatT0pC8kBM2+8Ja+S1t6B1v8WDVog2ZKbTlbU19kOqWx2lukdxZ6ZLZacf0= X-Received: by 2002:a05:6830:448c:b0:638:96f5:a077 with SMTP id r12-20020a056830448c00b0063896f5a077mr6785465otv.335.1661782545553; Mon, 29 Aug 2022 07:15:45 -0700 (PDT) MIME-Version: 1.0 References: <20220823114224.904934-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Mon, 29 Aug 2022 16:15:34 +0200 Message-ID: Subject: Re: [PATCH] Add support for floating point endpoints to frange. To: Toon Moene Cc: gcc-patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-6.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,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 Mon, Aug 29, 2022 at 4:08 PM Toon Moene wrote: > > On 8/29/22 15:54, Jakub Jelinek via Gcc-patches wrote: > > > On Mon, Aug 29, 2022 at 03:45:33PM +0200, Aldy Hernandez wrote: > > >> For convenience, singleton_p() returns false for a NAN. IMO, it makes > >> the implementation cleaner, but I'm not wed to the idea if someone > >> objects. > > > > If singleton_p() is used to decide whether one can just replace a variable > > with singleton range with a constant, then certainly. > > If MODE_HAS_SIGNED_ZEROS, zero has 2 representations (-0.0 and 0.0) and > > NaNs have lots of different representations (the sign bit is ignored > > except for stuff like copysign/signbit, there are qNaNs and sNaNs and > > except for the single case how Inf is represented, all other values of the > > mantissa mean different representations of NaN). So, unless we track which > > exact form of NaN can appear, NaN or any [x, x] range with NaN property > > set can't be a singleton. There could be programs that propagate something > > important in NaN mantissa and would be upset if frange kills that. > > Of course, one needs to take into account that when a FPU creates NaN, it > > will create the canonical qNaN. > > > > Jakub > > > > But the NaNs are irrelevant with -ffinite-math-only, as are the various > Infs (I do not know offhand which MODE_ that is) ... But even with -ffinite-math-only, is there any benefit to propagating a known NAN? For example: if (__builtin_isnan (x)) { use(x); } or perhaps: if (x != x) { use(x); } Should we propagate NAN into the use of x? For that matter, AFAICT we don't even generate the unordered comparisons needed to distinguish a NAN for -ffinite-math-only. void foo(float f) { if (__builtin_isnan (f)) bark(); } $ cat a.c.*original ;; Function foo (null) ;; enabled by -tree-original { if (0) { bark (); } } Cheers. Aldy