public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Aldy Hernandez <aldyh@redhat.com>
Cc: GCC patches <gcc-patches@gcc.gnu.org>
Subject: Re: [COMMITTED] Drop -0.0 in frange::set() for !HONOR_SIGNED_ZEROS.
Date: Fri, 14 Oct 2022 17:00:14 +0200	[thread overview]
Message-ID: <Y0l5fm1m0eyQwYDT@tucnak> (raw)
In-Reply-To: <CAGm3qMWHejP5kt=3iSdeOJfHUp3yjg7m+STpMf4BTvUueMXeBg@mail.gmail.com>

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 <aldyh@redhat.com>
> 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


  reply	other threads:[~2022-10-14 15:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-14 14:26 Aldy Hernandez
2022-10-14 14:26 ` [COMMITTED] Normalize ranges over the range for both bounds when -ffinite-math-only Aldy Hernandez
2022-10-14 14:26 ` [COMMITTED] Replace CFN_BUILTIN_SIGNBIT* cases with CASE_FLT_FN Aldy Hernandez
2022-10-14 14:32 ` [COMMITTED] Drop -0.0 in frange::set() for !HONOR_SIGNED_ZEROS Jakub Jelinek
2022-10-14 14:53   ` Aldy Hernandez
2022-10-14 15:00     ` Jakub Jelinek [this message]
2022-10-14 15:06       ` Aldy Hernandez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y0l5fm1m0eyQwYDT@tucnak \
    --to=jakub@redhat.com \
    --cc=aldyh@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).