From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2136) id 54328382DACF; Sun, 18 Sep 2022 07:04:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 54328382DACF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1663484645; bh=UOK6CEgAmEuqR5bNUYpt09iIJudwViJtA6srdgwd4JE=; h=From:To:Subject:Date:From; b=gDA1QObJfD+f5NRivCS9Jd9xUdIGRUGMh/4ja5qkXdfN8JGfIL1LkcKVE7IOJqnym jCoNOV7SaWi5tIQvPOAZYdhKhHrpzJLZ2ZGwejpQ0fHWlJhUSp5ipMzcxSie0SV40H dU5U3gzIjR8bFZS/Y3SBQKRA5ymt5qZSyzO1EWLY= MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" From: Aldy Hernandez To: gcc-cvs@gcc.gnu.org Subject: [gcc r13-2714] [PR106831] Avoid propagating long doubles that may have multiple representations. X-Act-Checkin: gcc X-Git-Author: Jakub Jelinek X-Git-Refname: refs/heads/master X-Git-Oldrev: 917461478d3bb733a64bc21876811d017c555b3c X-Git-Newrev: 5dba8b2a91376d0518eb21c69a0700f099aa9cc4 Message-Id: <20220918070405.54328382DACF@sourceware.org> Date: Sun, 18 Sep 2022 07:04:05 +0000 (GMT) List-Id: https://gcc.gnu.org/g:5dba8b2a91376d0518eb21c69a0700f099aa9cc4 commit r13-2714-g5dba8b2a91376d0518eb21c69a0700f099aa9cc4 Author: Jakub Jelinek Date: Sat Sep 17 08:50:22 2022 +0200 [PR106831] Avoid propagating long doubles that may have multiple representations. 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. PR middle-end/106831 gcc/ChangeLog: * value-range.cc (frange::singleton_p): Avoid propagating long doubles that may have multiple representations. Diff: --- 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;