From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from moene.org (84-86-97-173.fixed.kpn.net [84.86.97.173]) by sourceware.org (Postfix) with ESMTPS id 3018E3858D38 for ; Thu, 22 Sep 2022 19:23:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3018E3858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=moene.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=moene.org Received: from localhost ([127.0.0.1]) by moene.org with esmtp (Exim 4.96) (envelope-from ) id 1obRnC-000FcH-1G for gcc-patches@gcc.gnu.org; Thu, 22 Sep 2022 21:23:26 +0200 Message-ID: <30f228ad-3366-6def-5e61-3b59779832f4@moene.org> Date: Thu, 22 Sep 2022 21:23:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.1.2 Subject: Re: [PATCH] frange: dump hex values when dumping FP numbers. Content-Language: en-US To: gcc-patches@gcc.gnu.org References: <20220922164911.2566143-1-aldyh@redhat.com> From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands In-Reply-To: <20220922164911.2566143-1-aldyh@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-7.6 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KHOP_HELO_FCRDNS,NICE_REPLY_A,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: 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