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.133.124]) by sourceware.org (Postfix) with ESMTPS id C976638582B7 for ; Fri, 14 Oct 2022 15:00:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C976638582B7 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=1665759619; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=PrZSOWw4RHQuk7dm5PqpZGeW2IoQpxiHNQceV5FkzR0=; b=WOs+fM6WROszDTLlmvCeoUUj+oysx4A8lQlSCyC8eEju2P6foWd9xAyUsujwRXZl8wKiZp iHOMfIkTdKTLtSQ7xAWGKsFIa7gHLr2tmDOC1Jvltje463GmRVUe7gnUGEXAmeazQZFDYs 7X4uMhy80SvhIcvI6V1HVk5nj9fm6Xg= 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-50-vbiCNkZZNy6mtDphu3e5UA-1; Fri, 14 Oct 2022 11:00:18 -0400 X-MC-Unique: vbiCNkZZNy6mtDphu3e5UA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id F32503C138A5 for ; Fri, 14 Oct 2022 15:00:17 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.55]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AFDD121449A0; Fri, 14 Oct 2022 15:00:17 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 29EF0FbT2564165 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 14 Oct 2022 17:00:15 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 29EF0EfD2564164; Fri, 14 Oct 2022 17:00:14 +0200 Date: Fri, 14 Oct 2022 17:00:14 +0200 From: Jakub Jelinek To: Aldy Hernandez Cc: GCC patches Subject: Re: [COMMITTED] Drop -0.0 in frange::set() for !HONOR_SIGNED_ZEROS. Message-ID: Reply-To: Jakub Jelinek References: <20221014142652.671475-1-aldyh@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-10.1 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,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: On Fri, Oct 14, 2022 at 04:53:13PM +0200, Aldy Hernandez wrote: > > This looks wrong to me. > > !HONOR_NANS is different from !HONOR_SIGNED_ZEROS. > > The former says that either NaNs aren't supported or if they appear, > > it will be UB. > > The latter says that either -0.0 doesn't exist, or user doesn't care > > if -0.0 or 0.0 is used. > > > > So, what you do is ok for !MODE_HAS_SIGNED_ZEROS (TYPE_MODE (m_type)), > > but otherwise we want to canonicalize [x, -0.0] to [x, 0.0] and > > [0.0, y] to [-0.0, y]. > > If the user doesn't care, I would expect they'd be ok with it being > +0.0, but I must say, this is way beyond my paygrade. Unlike the NaN case where they can (easily) arrange for NaNs not to appear (say, avoid numerically undefined operations), for +/-0 if the hardware supports it they don't have much choice, sometimes computation will yield one, sometimes the other. The option is "I don't use anything that depends on the zero sign, which is e.g. copysign from zero, signbit or poking at the bit patterns". > How does this patch in testing look? LGTM (perhaps some comment would be nice though). > From 045d57b979722d15ce7fce733616bbf4ab0e0459 Mon Sep 17 00:00:00 2001 > From: Aldy Hernandez > Date: Fri, 14 Oct 2022 16:49:33 +0200 > Subject: [PATCH] Implement distinction between HONOR_SIGNED_ZEROS and > MODE_HAS_SIGNED_ZEROS. > > gcc/ChangeLog: > > * value-range.cc (frange::set): Implement distinction between > HONOR_SIGNED_ZEROS and MODE_HAS_SIGNED_ZEROS. > --- > gcc/value-range.cc | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/gcc/value-range.cc b/gcc/value-range.cc > index 6b4f3dddcd5..e5b4c1565d4 100644 > --- a/gcc/value-range.cc > +++ b/gcc/value-range.cc > @@ -324,13 +324,20 @@ frange::set (tree type, > m_neg_nan = false; > } > > - if (!HONOR_SIGNED_ZEROS (m_type)) > + if (!MODE_HAS_SIGNED_ZEROS (TYPE_MODE (m_type))) > { > if (real_iszero (&m_min, 1)) > m_min.sign = 0; > if (real_iszero (&m_max, 1)) > m_max.sign = 0; > } > + else if (!HONOR_SIGNED_ZEROS (m_type)) > + { > + if (real_iszero (&m_max, 1)) > + m_max.sign = 0; > + if (real_iszero (&m_min, 0)) > + m_min.sign = 1; > + } > > // For -ffinite-math-only we can drop ranges outside the > // representable numbers to min/max for the type. > -- > 2.37.3 > Jakub