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 E255B3858D28 for ; Wed, 9 Nov 2022 15:53:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E255B3858D28 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=1668009198; h=from:from:reply-to: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=AebNv48jGYCyTll/wB6nzz1veAdxYQ87PpnTLXXtYCk=; b=hKFzdVM2B2Mr02DFS48QfQYuRhr2HgMY4lG34T3n39uWlfidQVqW+F/yXCNO3Sp/m/qF6L aMjoDm22q+CHEO04gUv50blLrTduSp0agOX+jfozPhXjPbP5N/2nTRxP2qlCU8l2yCsMVY g7ddgCVegvICzQxyV6BqJ5ayA1Ojr18= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-612-qRvCJ35MN_SjvUeVkFIoHw-1; Wed, 09 Nov 2022 10:53:17 -0500 X-MC-Unique: qRvCJ35MN_SjvUeVkFIoHw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3EE811C09B75; Wed, 9 Nov 2022 15:53:17 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.194.183]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EC46D4EA49; Wed, 9 Nov 2022 15:53:16 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 2A9FrEGr4113128 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Wed, 9 Nov 2022 16:53:14 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2A9FrDvC4113127; Wed, 9 Nov 2022 16:53:13 +0100 Date: Wed, 9 Nov 2022 16:53:13 +0100 From: Jakub Jelinek To: Aldy Hernandez Cc: GCC patches , Andrew MacLeod , Xi Ruoyao Subject: Re: [COMMITTED] Implement op[12]_range operators for PLUS_EXPR and MINUS_EXPR. Message-ID: Reply-To: Jakub Jelinek References: <20221109090246.1036213-1-aldyh@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: On Wed, Nov 09, 2022 at 04:43:56PM +0100, Aldy Hernandez wrote: > 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? Yes. For implementation, perhaps just on the result of the reverse ops of whatever you do there currently (right before returning) call some function common to all binary ops that will handle the reverse op handling of NANs I've described. If lhs can't be NAN, then clear_nan on the result, if lhs is known to be NAN and other op can't be NAN, have result be known NAN (with VARYING sign), otherwise set maybe +-NAN on the result. Jakub