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 43AAB3858D3C for ; Mon, 5 Sep 2022 09:28:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 43AAB3858D3C 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=1662370121; 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=+icNjDXLFVfiAd7JybAQRAz2KQT/f4lU2lr8dnEPxZQ=; b=Gz8RB5mg9MmCtcyj7aELpuyOWX8YojSViM5BsZ9jUa/NjcjVXdQHJICTLsZh5x3K+RvsHT ajemuhfM3TKb1Nc0OXLaierl92VedUYUXfd0DraJ3A6AJc+eDkRhKJ33VWZxvilIn3bf5K 8iyJ000pE17i+0oCoCVbmp+26TvbkMg= 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-397-tuXtns0PPSWXp5BQ7CyhLg-1; Mon, 05 Sep 2022 05:28:40 -0400 X-MC-Unique: tuXtns0PPSWXp5BQ7CyhLg-1 Received: by mail-oo1-f70.google.com with SMTP id j9-20020a4ad2c9000000b004489186accbso3196336oos.4 for ; Mon, 05 Sep 2022 02:28:40 -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=+icNjDXLFVfiAd7JybAQRAz2KQT/f4lU2lr8dnEPxZQ=; b=4MViPxJUVBKQH+72/9Z1fw7f4o/7cJWTX2UMB16D9JpxNR4PdmBG1MoZ/9fWD9gC6f SOaw+LfXkKs1/iZ/tfsflwkk1l2UKv69dVhFiDIL2I3lENVbqrTpMuzmFn+3Y8kqrwGf NruMP27fNL1rnEz1Aff5zTQcDIQBDNodt83kZKkwNaK69DAYPQjFP6K9/hl5F5LahfwO J1H/dUFnrpk+0s6kaQ9y6oMSAtkNv6wvP1ivc1nHzKi7aepwulQz/xzVkrPkm/COFcvM bctp7X4edrC8Nygta3fdivUWywVu6V5/xT5Ztgt46LOmRB0tng2xe1KqG/ulCAq1haGY KOig== X-Gm-Message-State: ACgBeo0rQXBlIfLmFwFWTtfEVdNARCmoCWiOcecOVeNLpUx2vAjvCXJE GgslkTGB4ZCxDp8VCJDEDbQLRhG9HB+jx9faK4pk4kEc/ykS8td8P52Ux5lz1PY6b2mZF0ackHD 5N17XXtEuVu1pa8B0Lsm6c7jA/CGEZQBOIQ== X-Received: by 2002:a05:6870:210b:b0:10b:ed11:4e2d with SMTP id f11-20020a056870210b00b0010bed114e2dmr8820661oae.265.1662370119971; Mon, 05 Sep 2022 02:28:39 -0700 (PDT) X-Google-Smtp-Source: AA6agR52yfloiJO63MSFJS6o1zG6PXyB8CUenpQ5uG1jplXGY+m5LNQlHaLZKLGytHGQpl8CgQM/jt8wynTzT7bE5VQ= X-Received: by 2002:a05:6870:210b:b0:10b:ed11:4e2d with SMTP id f11-20020a056870210b00b0010bed114e2dmr8820646oae.265.1662370119748; Mon, 05 Sep 2022 02:28:39 -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:28:28 +0200 Message-ID: Subject: Re: [COMMITTED] Be even more conservative in intersection of NANs. To: Richard Biener Cc: Jakub Jelinek , 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:14 AM Richard Biener wrote: > > 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. > > Uh, that's confusing. So [3, 5] U maybe NAN intersected with > ][ NAN is ][ NAN. [3, 5] !NAN intersected with ][ NAN is ][ !NAN. I'm confused. What's ][ ??. For clarity in the discussion, let's say ?NAN, NAN, and !NAN for the NAN property. I would expect: [3,5] ?NAN U NAN = [3,5] ?NAN [3,5] !NAN U NAN = [3,5] ?NAN [3,5] !NAN ^ NAN = [] NAN !SIGN ^ NAN SIGN = [] (differing signs) [3,5] ?NAN ^ NAN = NAN [3,5] !NAN ^ NAN = [] Also, definite NANs must have a real_nan() on both sides of the endpoints. They must be the same. And that real_nan() could have a sign bit. So we could have: [NAN, NAN] ?SIGN (sign unknown-- default) [NAN, NAN] SIGN (negative NAN) [NAN, NAN] !SIGN (positive NAN) The above is enforced by the setter and verify_range. Note, that setting the definite NAN property (fp_prop::YES) to a range, makes it a NAN. That is, we will forcibly change the range to [NAN, NAN]. There's also an assert making sure you're not setting !NAN on a [NAN, NAN]. A varying has all the property bits set to unknown. So effectively ?NAN and ?SIGN. Do you agree? Aldy > > In fact [3, 5] U maybe NAN is just [3, 5] U NAN, there's no "maybe" ranges, > if the value may be NAN then NAN is in the value-range. So it's either > [3, 5] U NAN or [3, 5] (without U NAN). > > Richard. > > > > > Jakub > > >