public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Toon Moene <toon@moene.org>
To: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] frange: dump hex values when dumping FP numbers.
Date: Thu, 22 Sep 2022 21:23:26 +0200	[thread overview]
Message-ID: <30f228ad-3366-6def-5e61-3b59779832f4@moene.org> (raw)
In-Reply-To: <20220922164911.2566143-1-aldyh@redhat.com>

If it's not too cumbersome, I suggest dumping both.

In my neck-of-the-woods (meteorology) I have seen this done just to 
ensure that algorithms that are supposed to be bit-reproducable actually 
are - and that it can be checked visually.

Kind regards,
Toon.

On 9/22/22 18:49, Aldy Hernandez via Gcc-patches wrote:

> It has been suggested that if we start bumping numbers by an ULP when
> calculating open ranges (for example the numbers less than 3.0) that
> dumping these will become increasingly harder to read, and instead we
> should opt for the hex representation.  I still find the floating
> point representation easier to read for most numbers, but perhaps we
> could have both?
> 
> With this patch this is the representation for [15.0, 20.0]:
> 
>       [frange] float [1.5e+1 (0x0.fp+4), 2.0e+1 (0x0.ap+5)]
> 
> Would you find this useful, or should we stick to the hex
> representation only (or something altogether different)?
> 
> Tested on x86-64 Linux.
> 
> gcc/ChangeLog:
> 
> 	* value-range-pretty-print.cc (vrange_printer::print_real_value): New.
> 	(vrange_printer::visit): Call print_real_value.
> 	* value-range-pretty-print.h: New print_real_value.
> ---
>   gcc/value-range-pretty-print.cc | 16 ++++++++++++----
>   gcc/value-range-pretty-print.h  |  1 +
>   2 files changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/value-range-pretty-print.cc b/gcc/value-range-pretty-print.cc
> index eb7442229ba..51be037c254 100644
> --- a/gcc/value-range-pretty-print.cc
> +++ b/gcc/value-range-pretty-print.cc
> @@ -117,6 +117,16 @@ vrange_printer::print_irange_bitmasks (const irange &r) const
>     pp_string (pp, buf);
>   }
>   
> +void
> +vrange_printer::print_real_value (tree type, const REAL_VALUE_TYPE &r) const
> +{
> +  char s[60];
> +  tree t = build_real (type, r);
> +  dump_generic_node (pp, t, 0, TDF_NONE, false);
> +  real_to_hexadecimal (s, &r, sizeof (s), 0, 1);
> +  pp_printf (pp, " (%s)", s);
> +}
> +
>   // Print an frange.
>   
>   void
> @@ -141,11 +151,9 @@ vrange_printer::visit (const frange &r) const
>     bool has_endpoints = !r.known_isnan ();
>     if (has_endpoints)
>       {
> -      dump_generic_node (pp,
> -			 build_real (type, r.lower_bound ()), 0, TDF_NONE, false);
> +      print_real_value (type, r.lower_bound ());
>         pp_string (pp, ", ");
> -      dump_generic_node (pp,
> -			 build_real (type, r.upper_bound ()), 0, TDF_NONE, false);
> +      print_real_value (type, r.upper_bound ());
>       }
>     pp_character (pp, ']');
>     print_frange_nan (r);
> diff --git a/gcc/value-range-pretty-print.h b/gcc/value-range-pretty-print.h
> index 20c26598fe7..a9ae5a7b4cc 100644
> --- a/gcc/value-range-pretty-print.h
> +++ b/gcc/value-range-pretty-print.h
> @@ -32,6 +32,7 @@ private:
>     void print_irange_bound (const wide_int &w, tree type) const;
>     void print_irange_bitmasks (const irange &) const;
>     void print_frange_nan (const frange &) const;
> +  void print_real_value (tree type, const REAL_VALUE_TYPE &r) const;
>   
>     pretty_printer *pp;
>   };

-- 
Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands


  parent reply	other threads:[~2022-09-22 19:23 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-22 16:49 Aldy Hernandez
2022-09-22 16:49 ` [PATCH] frange: drop endpoints to min/max representable numbers for -ffinite-math-only Aldy Hernandez
2022-09-23  7:03   ` Richard Biener
2022-09-23  7:21     ` Aldy Hernandez
2022-09-23  7:51       ` Richard Biener
2022-09-22 19:23 ` Toon Moene [this message]
2022-09-22 19:25 ` [PATCH] frange: dump hex values when dumping FP numbers Jeff Law
2022-09-22 21:04 ` Jakub Jelinek
2022-09-23  6:56   ` 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=30f228ad-3366-6def-5e61-3b59779832f4@moene.org \
    --to=toon@moene.org \
    --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).