From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122933 invoked by alias); 4 May 2015 19:20:01 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 122513 invoked by uid 89); 4 May 2015 19:20:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 04 May 2015 19:19:59 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 5C2168E3ED for ; Mon, 4 May 2015 19:19:58 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-143.phx2.redhat.com [10.3.113.143]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t44JJv49014274; Mon, 4 May 2015 15:19:58 -0400 Message-ID: <5547C65D.3090807@redhat.com> Date: Mon, 04 May 2015 19:20:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: David Malcolm , gcc-patches@gcc.gnu.org Subject: Re: [PATCH 3/4] libcpp/input.c: Add a way to visualize the linemaps References: <1430528215-19648-1-git-send-email-dmalcolm@redhat.com> <1430528215-19648-4-git-send-email-dmalcolm@redhat.com> In-Reply-To: <1430528215-19648-4-git-send-email-dmalcolm@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-05/txt/msg00248.txt.bz2 On 05/01/2015 06:56 PM, David Malcolm wrote: > As a relative newcomer to GCC, one of the issues I had was > becoming comfortable with the linemap API and its internal > representation. > > To familiarize myself with it, I wrote a dumping routine > to try to visualize how the source_location space is carved > up between line maps, and what each number can mean. > > It struck me that this would benefit others, so this patch > adds this visualization, via an undocumented option > -fdump-locations, and adds a text file to libcpp's sources > documenting a simple example of compiling a small C file, > with a header and macro expansions (built using the > -fdump-locations option and a little hand-editing). > > gcc/ChangeLog: > * common.opt (fdump-locations): New option. > * input.c: Include diagnostic-core.h. > (get_end_location): New function. > (write_digit): New function. > (write_digit_row): New function. > (dump_location_range): New function. > (dump_labelled_location_range): New function. > (dump_location_info): New function. > * input.h (dump_location_info): New prototype. > * toplev.c (compile_file): Handle flag_dump_locations. > > libcpp/ChangeLog: > * include/line-map.h (source_location): Add a reference to > location-example.txt to the descriptive comment. > * location-example.txt: New file. Maybe "dump-internal-locations"? Not sure I want to bikeshed on the name any more than that. If you feel strongly about the option name, then I won't stress about it. > +void > +dump_location_info (FILE *stream) > +{ > + if (0) > + line_table_dump (stream, > + line_table, > + LINEMAPS_ORDINARY_USED (line_table), > + LINEMAPS_MACRO_USED (line_table)); Should the if (0) code go away? > + > + /* A brute-force visualization: emit a warning at every location. */ > + if (0) > + for (source_location loc = 0; loc < line_table->highest_location; loc++) > + warning_at (loc, 0, "this is location %i", loc); > + /* Alternatively, we could use inform (), though this > + also shows lots of locations in stdc-predef.h */ And again. So I think with removing the if (0) code and the possible option name change this is good to go. Jeff