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 364F63AA9410 for ; Sat, 17 Sep 2022 07:39:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 364F63AA9410 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=1663400382; 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: content-transfer-encoding:content-transfer-encoding; bh=KgYLF1EGiubQHsgSrRZMhduBhWJKht2zrJxel7ixrgo=; b=FP+58iQem4AWtI7V5WA7ISRI3DJRanDT1K6RPscK3Om2CwRRxhY7ebm140QTzxGGg12LKD fnDp7PY5fnVWyLQBx7kYdRNq0x+1ieDwh8euLISbI4g5lNnXxp/blffmDwl91ZzPuF0It3 ClIpRM3OAXSIGyZFE5R3L/xBNWOZsnA= 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-629-572WV3X-P--5QCBODnmL6g-1; Sat, 17 Sep 2022 03:39:36 -0400 X-MC-Unique: 572WV3X-P--5QCBODnmL6g-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 775D43C0218C; Sat, 17 Sep 2022 07:39:36 +0000 (UTC) Received: from abulafia.quesejoda.com (unknown [10.39.192.11]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 148B649BB60; Sat, 17 Sep 2022 07:39:35 +0000 (UTC) Received: from abulafia.quesejoda.com (localhost [127.0.0.1]) by abulafia.quesejoda.com (8.17.1/8.17.1) with ESMTPS id 28H7dYBk1542849 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 17 Sep 2022 09:39:34 +0200 Received: (from aldyh@localhost) by abulafia.quesejoda.com (8.17.1/8.17.1/Submit) id 28H7dX3X1542848; Sat, 17 Sep 2022 09:39:33 +0200 From: Aldy Hernandez To: Jakub Jelinek Cc: Joseph Myers , Andrew MacLeod , GCC patches , Aldy Hernandez Subject: [PATCH] [PR106831] Avoid propagating long doubles that may have multiple representations. Date: Sat, 17 Sep 2022 09:39:26 +0200 Message-Id: <20220917073926.1542752-1-aldyh@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-12.3 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_LOW,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: Long doubles are tricky when it comes to considering singletons because small numbers and +-INF can have multiple representations for the same number. So we need to be very careful not to treat those as singletons, lest they be incorrectly propagated by VRP. This is similar to the -0.0 and +0.0 duality. In long doubles +INF can be represented with +INF in the MSB and either -0.0 or +0.0 in the LSB. Similarly for numbers that are exactly representable in DF. For example, 1.0 can be represented as either (1.0, +0.0) or (1.0, -0.0). This patch avoids treating these numbers as singletons. Note that NANs in long double format have a LSB of don't care, but this is irrelevant for singleton_p, because NANs are never considered singletons. Also, internally in the frange we store NANs as a pair of boolean flags indicating whether they are +NAN or -NAN, so we don't need any special treatment here for comparing range equality etc. We never see anything but the boolean flags. (Errr, the boolean flags are not yet in trunk, but should go in shortly). I will push this patch after tests complete. Thank you Jakub for providing this patch. PR middle-end/106831 gcc/ChangeLog: * value-range.cc (frange::singleton_p): Avoid propagating long doubles that may have multiple representations. --- gcc/value-range.cc | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/gcc/value-range.cc b/gcc/value-range.cc index 55a216efd8b..67d5d7fa90f 100644 --- a/gcc/value-range.cc +++ b/gcc/value-range.cc @@ -639,6 +639,21 @@ frange::singleton_p (tree *result) const if (HONOR_NANS (m_type) && maybe_isnan ()) return false; + if (MODE_COMPOSITE_P (TYPE_MODE (m_type))) + { + // For IBM long doubles, if the value is +-Inf or is exactly + // representable in double, the other double could be +0.0 + // or -0.0. Since this means there is more than one way to + // represent a value, return false to avoid propagating it. + // See libgcc/config/rs6000/ibm-ldouble-format for details. + if (real_isinf (&m_min)) + return false; + REAL_VALUE_TYPE r; + real_convert (&r, DFmode, &m_min); + if (real_identical (&r, &m_min)) + return false; + } + if (result) *result = build_real (m_type, m_min); return true; -- 2.37.1