From patchwork Thu Nov 10 15:03:46 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Aldy Hernandez X-Patchwork-Id: 60354 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D07973858431 for ; Thu, 10 Nov 2022 15:04:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D07973858431 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1668092699; bh=I+UXqK5Egrw5gQb3F6L3HBzSfBfyTJILKKO0mcPBvPA=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=HEGlcej9r4k+PB2HFk8UWPzsXkNV3amq+3BJghOMVMnmBcmc/LbO5xz7ZbxECb2M3 GauJnMfSi9BKKG0KBt7OiVogS6NmbYRnDDd9ZIqtyN/+v72lQzXfyTmR5NsY/smCLu cwvWFkMWn/8TmsTEbic1kvjgFrNNx9z0BH8FFa3k= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org 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 403DF3858D20 for ; Thu, 10 Nov 2022 15:04:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 403DF3858D20 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-59-dlseYr0FM5OPxIC2HGlLBA-1; Thu, 10 Nov 2022 10:04:24 -0500 X-MC-Unique: dlseYr0FM5OPxIC2HGlLBA-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 7AB8D1C09049 for ; Thu, 10 Nov 2022 15:04:24 +0000 (UTC) Received: from abulafia.quesejoda.com (unknown [10.39.193.174]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1DC884EA5D; Thu, 10 Nov 2022 15:04:23 +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 2AAF4Llm157168 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 10 Nov 2022 16:04:21 +0100 Received: (from aldyh@localhost) by abulafia.quesejoda.com (8.17.1/8.17.1/Submit) id 2AAF4LaD157167; Thu, 10 Nov 2022 16:04:21 +0100 To: GCC patches Cc: Jakub Jelinek , Andrew MacLeod , Aldy Hernandez Subject: [PATCH] Do not specify NAN sign in frange::set_nonnegative. Date: Thu, 10 Nov 2022 16:03:46 +0100 Message-Id: <20221110150345.157116-1-aldyh@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-11.8 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_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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Aldy Hernandez via Gcc-patches From: Aldy Hernandez Reply-To: Aldy Hernandez Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" [Jakub, how's this? Do you agree?] After further reading of the IEEE 754 standard, it has become clear that there are no guarantees with regards to the sign of a NAN when it comes to any operation other than copy, copysign, abs, and negate. Currently, set_nonnegative() is only used in one place in ranger applicable to floating point values, when expanding unknown calls. Since we already specially handle copy, copysign, abs, and negate, all the calls to set_nonnegative() must be NAN-sign agnostic. The cleanest solution is to leave the sign unspecificied in frange::set_nonnegative(). Any special case, must be handled by the caller. gcc/ChangeLog: * value-range.cc (frange::set_nonnegative): Remove NAN sign handling. (range_tests_signed_zeros): Adjust test. --- gcc/value-range.cc | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/gcc/value-range.cc b/gcc/value-range.cc index 852ac09f2c4..d55d85846c1 100644 --- a/gcc/value-range.cc +++ b/gcc/value-range.cc @@ -797,14 +797,17 @@ frange::zero_p () const && real_iszero (&m_max)); } +// Set the range to non-negative numbers, that is [+0.0, +INF]. +// +// The NAN in the resulting range (if HONOR_NANS) has a varying sign +// as there are no guarantees in IEEE 754 wrt to the sign of a NAN, +// except for copy, abs, and copysign. It is the responsibility of +// the caller to set the NAN's sign if desired. + void frange::set_nonnegative (tree type) { set (type, dconst0, frange_val_max (type)); - - // Set +NAN as the only possibility. - if (HONOR_NANS (type)) - update_nan (/*sign=*/false); } // Here we copy between any two irange's. The ranges can be legacy or @@ -3923,7 +3926,6 @@ range_tests_signed_zeros () ASSERT_TRUE (r0.undefined_p ()); r0.set_nonnegative (float_type_node); - ASSERT_TRUE (r0.signbit_p (signbit) && !signbit); if (HONOR_NANS (float_type_node)) ASSERT_TRUE (r0.maybe_isnan ()); }