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 95E5B3857C61 for ; Thu, 22 Sep 2022 16:51:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 95E5B3857C61 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=1663865485; 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=/VO81USOHq2eKsGUap3wwfAFWNECGoZZ3ZHViB6n4pU=; b=Gfb4LqCluGs5dnqszD0DQ2dLHNoeokejpznMkhQUlhnsW7MoKPHhD5WxtCU54qiPUj6yz6 7OsUFkZ4Ugwl1a5HxeFzy4QfTR0h8GIAS+0LbdzW/67i8oHbxZgZCBaqhLi6vvvMjwqL54 ND0ECAEX9HPeQQhO1f9cPBpnfDcdhgg= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-28-RQzgbjriPcGVCu-f2pe-bQ-1; Thu, 22 Sep 2022 12:49:36 -0400 X-MC-Unique: RQzgbjriPcGVCu-f2pe-bQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 942CA872846; Thu, 22 Sep 2022 16:49:16 +0000 (UTC) Received: from abulafia.quesejoda.com (unknown [10.39.192.141]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 3703540C213F; Thu, 22 Sep 2022 16:49:16 +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 28MGnERD2566230 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 22 Sep 2022 18:49:14 +0200 Received: (from aldyh@localhost) by abulafia.quesejoda.com (8.17.1/8.17.1/Submit) id 28MGnEva2566229; Thu, 22 Sep 2022 18:49:14 +0200 From: Aldy Hernandez To: GCC patches Cc: Richard Biener , Jakub Jelinek , Andrew MacLeod , Aldy Hernandez Subject: [PATCH] frange: dump hex values when dumping FP numbers. Date: Thu, 22 Sep 2022 18:49:10 +0200 Message-Id: <20220922164911.2566143-1-aldyh@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 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_LOW,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: 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; }; -- 2.37.1