From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp07.smtpout.orange.fr [80.12.242.129]) by sourceware.org (Postfix) with ESMTPS id 8B8283858C50 for ; Tue, 27 Sep 2022 13:00:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8B8283858C50 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orange.fr Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr Received: from [192.168.1.17] ([86.215.174.255]) by smtp.orange.fr with ESMTPA id dAC6otob2r5PddAC6oAdiR; Tue, 27 Sep 2022 15:00:16 +0200 X-ME-Helo: [192.168.1.17] X-ME-Auth: bW9yaW4tbWlrYWVsQG9yYW5nZS5mcg== X-ME-Date: Tue, 27 Sep 2022 15:00:16 +0200 X-ME-IP: 86.215.174.255 Message-ID: <46a9380d-2cd5-7bfb-ecc7-a33a8369338b@orange.fr> Date: Tue, 27 Sep 2022 15:00:14 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Subject: Re: [PATCH] Rewrite NAN and sign handling in frange Content-Language: fr, en-US To: gcc-patches@gcc.gnu.org References: <20220915054026.1359564-1-aldyh@redhat.com> From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-11.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,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: Hello, Le 16/09/2022 à 15:26, Aldy Hernandez via Gcc-patches a écrit : > diff --git a/gcc/value-range.cc b/gcc/value-range.cc > index d759fcf178c..55a216efd8b 100644 > --- a/gcc/value-range.cc > +++ b/gcc/value-range.cc > @@ -617,21 +602,24 @@ frange::contains_p (tree cst) const > if (varying_p ()) > return true; > (...) > > if (real_compare (GE_EXPR, rv, &m_min) && real_compare (LE_EXPR, rv, &m_max)) > { > + // Make sure the signs are equal for signed zeros. > if (HONOR_SIGNED_ZEROS (m_type) && real_iszero (rv)) > - { > - // FIXME: This is still using get_signbit() instead of > - // known_signbit() because the latter bails on possible NANs > - // (for now). > - if (get_signbit ().yes_p ()) > - return real_isneg (rv); > - else if (get_signbit ().no_p ()) > - return !real_isneg (rv); > - else > - return true; > - } > + return m_min.sign == m_max.sign && m_min.sign == rv->sign; > return true; > } > return false; It seems that this won't report any range with mismatching bound signs as containing zero. Maybe a selftest explains it better: the following fails. diff --git a/gcc/value-range.cc b/gcc/value-range.cc index 9ca442478c9..8fc909171bc 100644 --- a/gcc/value-range.cc +++ b/gcc/value-range.cc @@ -3780,6 +3780,14 @@ range_tests_signed_zeros () ASSERT_TRUE (r0.contains_p (neg_zero)); ASSERT_FALSE (r0.contains_p (zero)); + r0 = frange_float ("-3", "5"); + ASSERT_TRUE (r0.contains_p (neg_zero)); + ASSERT_TRUE (r0.contains_p (zero)); + + r0 = frange (neg_zero, zero); + ASSERT_TRUE (r0.contains_p (neg_zero)); + ASSERT_TRUE (r0.contains_p (zero)); + // The intersection of zeros that differ in sign is a NAN (or // undefined if not honoring NANs). r0 = frange (neg_zero, neg_zero);