From patchwork Mon Oct 10 11:40:05 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Paolo Carlini X-Patchwork-Id: 118721 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 131AFB71A4 for ; Mon, 10 Oct 2011 22:42:07 +1100 (EST) Received: (qmail 28960 invoked by alias); 10 Oct 2011 11:42:05 -0000 Received: (qmail 28952 invoked by uid 22791); 10 Oct 2011 11:42:05 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from rcsinet15.oracle.com (HELO rcsinet15.oracle.com) (148.87.113.117) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 10 Oct 2011 11:41:51 +0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by rcsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id p9ABfir9032079 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 10 Oct 2011 11:41:46 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id p9ABfhmQ022696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Oct 2011 11:41:44 GMT Received: from abhmt104.oracle.com (abhmt104.oracle.com [141.146.116.56]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id p9ABfbou019594; Mon, 10 Oct 2011 06:41:38 -0500 Received: from [192.168.1.4] (/79.53.14.153) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 10 Oct 2011 04:41:37 -0700 Message-ID: <4E92D995.2070907@oracle.com> Date: Mon, 10 Oct 2011 13:40:05 +0200 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: "gcc-patches@gcc.gnu.org" CC: "Joseph S. Myers" , Gabriel Dos Reis , Jason Merrill Subject: [C++ Patch / RFC] PR 33067 X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi, reporter complains that, for: struct T {} t; bool b = 1.1 < t; we output (on x86_64-linux): 33067.C:2:18: error: no match for ‘operator<’ in ‘1.100000000000000088817841970012523233890533447265625e+0 < t’ which is clearly pretty dumb. In my opinion, a definite improvement would be following: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1822.pdf thus output a "minimal" number of decimal digits. If I apply the attached patchlet, I get: 33067.C:2:18: error: no match for ‘operator<’ in ‘1.1000000000000001e+0 < t’ which looks much better to me. Comments? Does the idea make sense to everybody? Thanks, Paolo. PS: I didn't carefully check the decimal floating point case, maybe we could do better. //////////////////// Index: c-family/c-pretty-print.c =================================================================== --- c-family/c-pretty-print.c (revision 179739) +++ c-family/c-pretty-print.c (working copy) @@ -1018,8 +1018,19 @@ pp_c_enumeration_constant (c_pretty_printer *pp, t static void pp_c_floating_constant (c_pretty_printer *pp, tree r) { + const struct real_format *fmt + = REAL_MODE_FORMAT (TYPE_MODE (TREE_TYPE (r))); + + REAL_VALUE_TYPE floating_cst = TREE_REAL_CST (r); + bool is_decimal = floating_cst.decimal; + + // The fraction 643/2136 approximates log10(2) to 7 significant digits. + int max_digits10 = 2 + (is_decimal ? fmt->p : fmt->p * 643L / 2136); + real_to_decimal (pp_buffer (pp)->digit_buffer, &TREE_REAL_CST (r), - sizeof (pp_buffer (pp)->digit_buffer), 0, 1); + sizeof (pp_buffer (pp)->digit_buffer), + max_digits10, 1); + pp_string (pp, pp_buffer(pp)->digit_buffer); if (TREE_TYPE (r) == float_type_node) pp_character (pp, 'f');