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 DB5943858D32 for ; Mon, 5 Sep 2022 09:12:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org DB5943858D32 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=1662369130; 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=hgoH0T1ockJgm/21LCg84Q+iPH83UJEJl1Dzxy20gOY=; b=ZteDRnmyOI9k29mji2aNn0ahyKArh6VQ48EM4GEDJjFsvyxiTFp7gwDHc/1Diu4ATp0N1t Crz6ncQIDGoGOrLjZOyC1+BVtGzsKqBycMJ7XCQQGUFq3QTG2ipNvgxMQwsSdtDKPlsLp/ d6DHrOcBTwrsKUpdV8yxEynn3o1aWcQ= Received: from mail-oo1-f70.google.com (mail-oo1-f70.google.com [209.85.161.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-553-UhQWqNmNPzCRMvR1BlZmig-1; Mon, 05 Sep 2022 05:12:09 -0400 X-MC-Unique: UhQWqNmNPzCRMvR1BlZmig-1 Received: by mail-oo1-f70.google.com with SMTP id z15-20020a4a304f000000b0044b0ae69807so3172439ooz.9 for ; Mon, 05 Sep 2022 02:12:09 -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:subject:date; bh=hgoH0T1ockJgm/21LCg84Q+iPH83UJEJl1Dzxy20gOY=; b=TmsCZqFXhh3iPiSzOAIeB5/x/3ns3hLVXgqMxqlJkfM8YuVIo4iY29A9LJWasXJ1Gz cICUNWxa8TYE2MepefjuPq9cw9pHwHxI4BcTo+KMl6f5o+XRSf05CCrCEXMjWA3dXQxI TNWdEh4ivXOmx+DO0dC5c679LYLzj+PwWeszqF4xmOnPA5LEAV3ZeiQTNZeZOZmicPEn JWNGy7Q0Y32oMlfzNVP9Gibu7pG+417RIPwoBcXZQNqD3/p3IQsU4MrHVYrFkYmYlzTG 6axkauIwzEhaFjcpxcdCqmhq3na2w3hhpaIgUO27l7GHMKSS17kp8Kx1py0TBazactAD fcBQ== X-Gm-Message-State: ACgBeo3Hw2um0K8lKDnnJobSo2+mvgkm2kKPdxONVcnqKiRNscBLegHl O/50d3r0S/9uL8X3gN3zx+LJ68pv8ruafZragZJw4wCJrsSw6bEupIz6K/twpdM2gaaZ6yuc43Q NjkFfr6UG0uNp6/568WTO1zHS+FxhStNa3A== X-Received: by 2002:a4a:5e82:0:b0:44a:fe22:baff with SMTP id h124-20020a4a5e82000000b0044afe22baffmr16776756oob.86.1662369128818; Mon, 05 Sep 2022 02:12:08 -0700 (PDT) X-Google-Smtp-Source: AA6agR76hjXHyT1yWtBgfaP6XcyNjbOMY8X8h6nfbmDv+dsvYRnOwIWLrCGPXJVtdUIVYrOUNpN81ugCMbiTw15qpz0= X-Received: by 2002:a4a:5e82:0:b0:44a:fe22:baff with SMTP id h124-20020a4a5e82000000b0044afe22baffmr16776750oob.86.1662369128587; Mon, 05 Sep 2022 02:12:08 -0700 (PDT) MIME-Version: 1.0 References: <20220905062301.3240191-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Mon, 5 Sep 2022 11:11:57 +0200 Message-ID: Subject: Re: [COMMITTED] Be even more conservative in intersection of NANs. To: Jakub Jelinek , "MacLeod, Andrew" Cc: Richard Biener , GCC patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-5.7 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, Sep 5, 2022 at 11:06 AM Jakub Jelinek wrote: > > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote: > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches > > wrote: > > > > > > Intersecting two ranges where one is a NAN is keeping the sign bit of > > > the NAN range. This is not correct as the sign bits may not match. > > > > > > I think the only time we're absolutely sure about the intersection of > > > a NAN and something else, is when both are a NAN with exactly the same > > > properties (sign bit). If we're intersecting two NANs of differing > > > sign, we can decide later whether that's undefined or just a NAN with > > > no known sign. For now I've done the latter. > > > > > > I'm still mentally working on intersections involving NANs, especially > > > if we want to keep track of signbits. For now, let's be extra careful > > > and only do things we're absolutely sure about. > > > > > > Later we may want to fold the intersect of [NAN,NAN] and say [3,5] > > > with the posibility of NAN, to a NAN, but I'm not 100% sure. > > > > The intersection of [NAN, NAN] and [3, 5] is empty. The intersection > > of [NAN, NAN] and VARYING is [NAN, NAN]. > > I think [3.0, 5.0] printed that way currently means U maybe NAN, > it would be [3.0, 5.0] !NAN if it was known not to be NAN. Right. I don't print any of the "maybe" properties, just if they're definitely set or definitely clear. I'm open to suggestions as to how to display them. Perhaps NAN, !NAN, ?NAN. I'm mostly worried about removing a NAN from the IL that was going to signal, or some such. While I agree with you Richard, I just want to make real sure, because getting something wrong in the frange or range-ops bowels means the problem becomes pervasive to all of ranger ...and threader...and loop ch...and vrp, etc etc. I just want to take more time to test things. I promise it won't stay varying too long. Aldy