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 403DF3858D20 for ; Thu, 10 Nov 2022 15:04:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 403DF3858D20 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=1668092666; 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=I+UXqK5Egrw5gQb3F6L3HBzSfBfyTJILKKO0mcPBvPA=; b=emF7aBxdmn0+QrrUUAF7/usnJ7hAArfoQM/m1W3KqWXVYO22WVx8McB0v/z8BbzaBqxGen Ye+VL96w4TxVBP80hZ/KpNmUHXF5e0dvo2uRhpg1S08jVH3W0YdTHXO23DONfO7F7MoFXE NJNRElQe3t3yLBnqo2GiMO5TprHZz4k= 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 From: Aldy Hernandez 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 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true 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 List-Id: [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 ()); } -- 2.38.1