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.133.124]) by sourceware.org (Postfix) with ESMTPS id 8E8383858D20 for ; Wed, 9 Nov 2022 15:44:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8E8383858D20 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=1668008650; 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=wYW6EXFA5XJsYBbmE1IJdr6K+236SwFiDe2kBB0ztH4=; b=aTMf5Vsc5ATZq92CC4chW0SIqD6RcQ17vBhKUsv6osSGP2tD/4/Pln+xVVLJrJH7jC/YE4 fy5cDIgkUW/s22qziyiLbU79ouES6z5iWMA4iRZf6SAd4epkXtxegcMTMyL0KUqZOErXWi 7rasqVWdkKqjo1sUEtisRM9IHVqf4ys= Received: from mail-yb1-f199.google.com (mail-yb1-f199.google.com [209.85.219.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-620-9NccBPbKOFGzoL5xuVzecQ-1; Wed, 09 Nov 2022 10:44:08 -0500 X-MC-Unique: 9NccBPbKOFGzoL5xuVzecQ-1 Received: by mail-yb1-f199.google.com with SMTP id t6-20020a25b706000000b006b38040b6f7so16944543ybj.6 for ; Wed, 09 Nov 2022 07:44:08 -0800 (PST) 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:message-id :reply-to; bh=wYW6EXFA5XJsYBbmE1IJdr6K+236SwFiDe2kBB0ztH4=; b=VHXlP4JheUfi6iy9Ow4byR7JJlM6lzyi5NYnuy3+X0tZZRZBBG6kqLb91/HJRz3gUQ PFrj7mE928jvtjOXUp2Ami8QZTnSfWxeIVfAZ+S4FQoN1sWnXFBVlO94PONAjc2wByjT h9aHcx7g9d6oaiOYZu6V11ggYaY7S8nD1v8DU5WWKcl31ec4lzVEJ02KXs2P+ANWvpg4 oSS9lYzh7kVejJP1dgHugHFyLs5WLPl9F0oAzz6G9GK1rHiwQNQVvpGYyZ14G50vfoFt 20RSybaWVClWlS0o06XlxgoFoXijXAX/alRG8E/Gj6/fXITVNp1tCXHcoOgIN3TyO5a1 2MUg== X-Gm-Message-State: ACrzQf3gleg4AG324SIsvIN96wzAbvJsMPWdIcGb90g36A+AgaK4vZMp zujF+nMpviuqARv2R6xYeOV1QFozIa9b6eSziITssgjVy6+8EX53ZazoICCnFQbTDOpqTnUPbsi dQ2ve9NgsUHdG03Q5KP6xMuXQX39XFvdrQg== X-Received: by 2002:a25:aa48:0:b0:6cc:57f3:4a with SMTP id s66-20020a25aa48000000b006cc57f3004amr53894601ybi.109.1668008648125; Wed, 09 Nov 2022 07:44:08 -0800 (PST) X-Google-Smtp-Source: AMsMyM4ux6PeNMqKQXkfTRANz2X2+Fc3z+9iSnCyQnIe7XDDc1BZrilBfc0UvwHaRo/aYu+P3Xi4p5uiRiMrFgux818= X-Received: by 2002:a25:aa48:0:b0:6cc:57f3:4a with SMTP id s66-20020a25aa48000000b006cc57f3004amr53894580ybi.109.1668008647868; Wed, 09 Nov 2022 07:44:07 -0800 (PST) MIME-Version: 1.0 References: <20221109090246.1036213-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Wed, 9 Nov 2022 16:43:56 +0100 Message-ID: Subject: Re: [COMMITTED] Implement op[12]_range operators for PLUS_EXPR and MINUS_EXPR. To: Jakub Jelinek Cc: GCC patches , Andrew MacLeod , Xi Ruoyao X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="000000000000f090a405ed0b867f" X-Spam-Status: No, score=-11.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP 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: --000000000000f090a405ed0b867f Content-Type: text/plain; charset="UTF-8" On Wed, Nov 9, 2022 at 3:58 PM Jakub Jelinek wrote: > > On Wed, Nov 09, 2022 at 10:02:46AM +0100, Aldy Hernandez wrote: > > We can implement the op[12]_range entries for plus and minus in terms > > of each other. These are adapted from the integer versions. > > I think for NANs the op[12]_range shouldn't act this way. > For the forward binary operations, we have the (maybe/known) NAN handling > of one or both NAN operands resulting in VARYING sign (maybe/known) NAN > result, that is the somehow the case for the reverse binary operations too, > if result is (maybe/known) NAN and the other op is not NAN, op is > VARYING sign (maybe/known) NAN, if other op is (maybe/known) NAN, > then op is VARYING sign maybe NAN (always maybe, never known). > But then for + we have the -INF + INF or vice versa into NAN, and that > is something that shouldn't be considered. If result isn't NAN, then > neither operand can be NAN, regardless of whether result can be > +/- INF and the other op -/+ INF. Heh. I just ran into this while debugging the problem reported by Xi. We are solving NAN = op1 - VARYING, and trying to do it with op1 = NAN + VARYING, which returns op1 = NAN (incorrectly). I suppose in the above case op1 should ideally be [-INF,-INF][+INF,+INF]+-NAN, but since we can't represent that then [-INF,+INF] +-NAN, which is actually VARYING. Do you agree? I'm reverting this patch as attached, while I sort this out. Thanks. Aldy --000000000000f090a405ed0b867f Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Revert-op-12-_range-operators-for-PLUS_EXPR-and-MINU.patch" Content-Disposition: attachment; filename="0001-Revert-op-12-_range-operators-for-PLUS_EXPR-and-MINU.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_la9t55ji0 RnJvbSBmOGFjMmIxNWQxY2U4Y2JiMmY0YTRiYTg5YWZiZDg3YThhYTVjNGU2IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBbGR5IEhlcm5hbmRleiA8YWxkeWhAcmVkaGF0LmNvbT4KRGF0 ZTogV2VkLCA5IE5vdiAyMDIyIDE2OjM1OjQwICswMTAwClN1YmplY3Q6IFtQQVRDSF0gUmV2ZXJ0 IG9wWzEyXV9yYW5nZSBvcGVyYXRvcnMgZm9yIFBMVVNfRVhQUiBhbmQgTUlOVVNfRVhQUi4KClJl dmVydCB0aGUgcGF0Y2ggYmVsb3cgdW50aWwgaXNzdWVzIGFyZSByZXNvbHZlZDoKCgljb21taXQg NDI4N2U4MTY4Zjg5ZTkwYjNkZmYzYTUwZjNhZGE0MGJlNTNlMGUwMQoJQXV0aG9yOiBBbGR5IEhl cm5hbmRleiA8YWxkeWhAcmVkaGF0LmNvbT4KCURhdGU6ICAgV2VkIE5vdiA5IDAxOjAwOjU3IDIw MjIgKzAxMDAKCgkgICAgSW1wbGVtZW50IG9wWzEyXV9yYW5nZSBvcGVyYXRvcnMgZm9yIFBMVVNf RVhQUiBhbmQgTUlOVVNfRVhQUi4KCgkgICAgV2UgY2FuIGltcGxlbWVudCB0aGUgb3BbMTJdX3Jh bmdlIGVudHJpZXMgZm9yIHBsdXMgYW5kIG1pbnVzIGluIHRlcm1zCgkgICAgb2YgZWFjaCBvdGhl ci4gIFRoZXNlIGFyZSBhZGFwdGVkIGZyb20gdGhlIGludGVnZXIgdmVyc2lvbnMuCgpnY2MvQ2hh bmdlTG9nOgoKCSogcmFuZ2Utb3AtZmxvYXQuY2MgKGNsYXNzIGZvcGVyYXRvcl9wbHVzKTogUmVt b3ZlIG9wWzEyXV9yYW5nZS4KCShjbGFzcyBmb3BlcmF0b3JfbWludXMpOiBTYW1lLgotLS0KIGdj Yy9yYW5nZS1vcC1mbG9hdC5jYyB8IDQ1IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0KIDEgZmlsZSBjaGFuZ2VkLCA0NSBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQg YS9nY2MvcmFuZ2Utb3AtZmxvYXQuY2MgYi9nY2MvcmFuZ2Utb3AtZmxvYXQuY2MKaW5kZXggY2M4 MDY0MzhhMTkuLjM4MDE0MmI0YzE0IDEwMDY0NAotLS0gYS9nY2MvcmFuZ2Utb3AtZmxvYXQuY2MK KysrIGIvZ2NjL3JhbmdlLW9wLWZsb2F0LmNjCkBAIC0xODYzLDI5ICsxODYzLDYgQEAgZm9wZXJh dG9yX3Vub3JkZXJlZF9lcXVhbDo6b3AxX3JhbmdlIChmcmFuZ2UgJnIsIHRyZWUgdHlwZSwKIAog Y2xhc3MgZm9wZXJhdG9yX3BsdXMgOiBwdWJsaWMgcmFuZ2Vfb3BlcmF0b3JfZmxvYXQKIHsKLSAg dXNpbmcgcmFuZ2Vfb3BlcmF0b3JfZmxvYXQ6Om9wMV9yYW5nZTsKLSAgdXNpbmcgcmFuZ2Vfb3Bl cmF0b3JfZmxvYXQ6Om9wMl9yYW5nZTsKLXB1YmxpYzoKLSAgdmlydHVhbCBib29sIG9wMV9yYW5n ZSAoZnJhbmdlICZyLCB0cmVlIHR5cGUsCi0JCQkgIGNvbnN0IGZyYW5nZSAmbGhzLAotCQkJICBj b25zdCBmcmFuZ2UgJm9wMiwKLQkJCSAgcmVsYXRpb25fdHJpbyA9IFRSSU9fVkFSWUlORykgY29u c3QgZmluYWwgb3ZlcnJpZGUKLSAgewotICAgIGlmIChsaHMudW5kZWZpbmVkX3AgKCkpCi0gICAg ICByZXR1cm4gZmFsc2U7Ci0gICAgcmFuZ2Vfb3BfaGFuZGxlciBtaW51cyAoTUlOVVNfRVhQUiwg dHlwZSk7Ci0gICAgaWYgKCFtaW51cykKLSAgICAgIHJldHVybiBmYWxzZTsKLSAgICByZXR1cm4g bWludXMuZm9sZF9yYW5nZSAociwgdHlwZSwgbGhzLCBvcDIpOwotICB9Ci0gIHZpcnR1YWwgYm9v bCBvcDJfcmFuZ2UgKGZyYW5nZSAmciwgdHJlZSB0eXBlLAotCQkJICBjb25zdCBmcmFuZ2UgJmxo cywKLQkJCSAgY29uc3QgZnJhbmdlICZvcDEsCi0JCQkgIHJlbGF0aW9uX3RyaW8gPSBUUklPX1ZB UllJTkcpIGNvbnN0IGZpbmFsIG92ZXJyaWRlCi0gIHsKLSAgICByZXR1cm4gb3AxX3JhbmdlIChy LCB0eXBlLCBsaHMsIG9wMSk7Ci0gIH0KLXByaXZhdGU6CiAgIHZvaWQgcnZfZm9sZCAoUkVBTF9W QUxVRV9UWVBFICZsYiwgUkVBTF9WQUxVRV9UWVBFICZ1YiwgYm9vbCAmbWF5YmVfbmFuLAogCQl0 cmVlIHR5cGUsCiAJCWNvbnN0IFJFQUxfVkFMVUVfVFlQRSAmbGhfbGIsCkBAIC0xOTEwLDI4ICsx ODg3LDYgQEAgcHJpdmF0ZToKIAogY2xhc3MgZm9wZXJhdG9yX21pbnVzIDogcHVibGljIHJhbmdl X29wZXJhdG9yX2Zsb2F0CiB7Ci0gIHVzaW5nIHJhbmdlX29wZXJhdG9yX2Zsb2F0OjpvcDFfcmFu Z2U7Ci0gIHVzaW5nIHJhbmdlX29wZXJhdG9yX2Zsb2F0OjpvcDJfcmFuZ2U7Ci1wdWJsaWM6Ci0g IHZpcnR1YWwgYm9vbCBvcDFfcmFuZ2UgKGZyYW5nZSAmciwgdHJlZSB0eXBlLAotCQkJICBjb25z dCBmcmFuZ2UgJmxocywKLQkJCSAgY29uc3QgZnJhbmdlICZvcDIsCi0JCQkgIHJlbGF0aW9uX3Ry aW8gPSBUUklPX1ZBUllJTkcpIGNvbnN0IGZpbmFsIG92ZXJyaWRlCi0gIHsKLSAgICBpZiAobGhz LnVuZGVmaW5lZF9wICgpKQotICAgICAgcmV0dXJuIGZhbHNlOwotICAgIHJldHVybiBmb3BfcGx1 cy5mb2xkX3JhbmdlIChyLCB0eXBlLCBsaHMsIG9wMik7Ci0gIH0KLSAgdmlydHVhbCBib29sIG9w Ml9yYW5nZSAoZnJhbmdlICZyLCB0cmVlIHR5cGUsCi0JCQkgIGNvbnN0IGZyYW5nZSAmbGhzLAot CQkJICBjb25zdCBmcmFuZ2UgJm9wMSwKLQkJCSAgcmVsYXRpb25fdHJpbyA9IFRSSU9fVkFSWUlO RykgY29uc3QgZmluYWwgb3ZlcnJpZGUKLSAgewotICAgIGlmIChsaHMudW5kZWZpbmVkX3AgKCkp Ci0gICAgICByZXR1cm4gZmFsc2U7Ci0gICAgcmV0dXJuIGZvbGRfcmFuZ2UgKHIsIHR5cGUsIG9w MSwgbGhzKTsKLSAgfQotcHJpdmF0ZToKICAgdm9pZCBydl9mb2xkIChSRUFMX1ZBTFVFX1RZUEUg JmxiLCBSRUFMX1ZBTFVFX1RZUEUgJnViLCBib29sICZtYXliZV9uYW4sCiAJCXRyZWUgdHlwZSwK IAkJY29uc3QgUkVBTF9WQUxVRV9UWVBFICZsaF9sYiwKLS0gCjIuMzguMQoK --000000000000f090a405ed0b867f--