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 A64A33895FE8 for ; Mon, 5 Dec 2022 09:37:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A64A33895FE8 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=1670233074; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=HIrOFTuJT1v+GdgTetPSg9CbbvqrSZ7WDp+T3wRO4is=; b=RuwugbWinbOG/mqV8tUX664312n2azAfwY6mMPma7wR7D1SyRD9nRaqD12a2MnATyf1+a5 CELYidhqQo1Vq3HLA5nK/ZYNJNfRf2VHoA9b1zDBaLz25osfcUIkX2WLNTHMvb3Sce9dCo 0e4iRDH37o4oSrP+h/Ay3Am2RNK6Lmw= 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-462-Fw64guU3PSugLBb7BdLHgw-1; Mon, 05 Dec 2022 04:37:53 -0500 X-MC-Unique: Fw64guU3PSugLBb7BdLHgw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id DB43D1C0897A for ; Mon, 5 Dec 2022 09:37:52 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.195.114]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8ED1640C6EC3; Mon, 5 Dec 2022 09:37:52 +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 2B59bluF3408988 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 5 Dec 2022 10:37:48 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 2B59blMe3408987; Mon, 5 Dec 2022 10:37:47 +0100 Date: Mon, 5 Dec 2022 10:37:46 +0100 From: Jakub Jelinek To: Aldy Hernandez Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH] range-op-float: Fix up multiplication and division reverse operation [PR107879] Message-ID: Reply-To: Jakub Jelinek References: <1f2b50a8-8f3c-690a-182b-c636fc2f86ed@redhat.com> MIME-Version: 1.0 In-Reply-To: <1f2b50a8-8f3c-690a-182b-c636fc2f86ed@redhat.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit 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 Mon, Dec 05, 2022 at 10:20:53AM +0100, Aldy Hernandez wrote: > > For the division, [-0., 0.] / VARYING is computed (IMHO correctly) > > as [-0., 0.] +-NAN, because 0 / anything but 0 or NAN is still > > 0 and 0 / 0 is NAN and ditto 0 / NAN. And then we just > > float_binary_op_range_finish, which figures out that because lhs > > can't be NAN, neither operand can be NAN. So, the end range is > > [-0., 0.]. But that is not correct for the reverse multiplication. > > When the result is 0, if op2 can be zero, then x can be anything > > (VARYING), to be precise anything but INF (unless result can be NAN), > > Not an objection, just an observation... If we know it can't be INF, could > we drop INF from the range? We have frange_drop_{inf,ninf} for this. Do you mind if I try that incrementally and only if it doesn't make the code too large/too unreadable? > > + // If both lhs and op2 could be zeros or both could be infinities, > > + // we don't know anything about op1 except maybe for the sign > > + // and perhaps if it can be NAN or not. > > + REAL_VALUE_TYPE lb, ub; > > + int signbit_known = signbit_known_p (lhs_lb, lhs_ub, op2_lb, op2_ub); > > + zero_to_inf_range (lb, ub, signbit_known); > > + r.set (type, lb, ub); > > I assume we don't know anything about the sign of the NAN because of all the > weird IEEE rules? Yes, sign bit of NAN is unknown after binary operation or even in the reverse case of binary operations. The sign rule is for non-NAN. "When neither the inputs nor result are NaN, the sign of a product or quotient is the exclusive OR of the operands' signs; the sign of a sum, or of a difference x–y regarded as a sum x+(–y), differs from at most one of the addends' signs; and the sign of the result of the roundToIntegral operations and roundToIntegralExact (see 7.3.1) is the sign of the operand. These rules shall apply even when operands or results are zero or infinite." Jakub