From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11922 invoked by alias); 1 Aug 2011 18:54:18 -0000 Received: (qmail 11910 invoked by uid 22791); 1 Aug 2011 18:54:17 -0000 X-SWARE-Spam-Status: No, hits=-6.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Aug 2011 18:54:02 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p71IrWVJ023091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2011 14:53:32 -0400 Received: from localhost (ovpn-113-31.phx2.redhat.com [10.3.113.31]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p71IrUMU008573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Aug 2011 14:53:31 -0400 Received: by localhost (Postfix, from userid 500) id 3937B29C06A; Mon, 1 Aug 2011 20:53:29 +0200 (CEST) From: Dodji Seketeli To: Jason Merrill Cc: gcc-patches@gcc.gnu.org, tromey@redhat.com, gdr@integrable-solutions.net, joseph@codesourcery.com, burnus@net-b.de, charlet@act-europe.fr, paolo@gnu.org Subject: Re: [PATCH 1/7] Linemap infrastructure for virtual locations References: <1291979498-1604-1-git-send-email-dodji@redhat.com> <3d6fbfd16f0e3493839205de1266eaaa8dbb9c77.1310824121.git.dodji@redhat.com> <4E334A10.3020602@redhat.com> X-URL: http://www.redhat.com Date: Mon, 01 Aug 2011 18:54:00 -0000 In-Reply-To: <4E334A10.3020602@redhat.com> (Jason Merrill's message of "Fri, 29 Jul 2011 17:02:24 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 X-SW-Source: 2011-08/txt/msg00083.txt.bz2 Jason Merrill writes: > On 07/16/2011 07:37 AM, Dodji Seketeli wrote: >> +/* Returns the highest location [of a token resulting from macro >> + expansion] encoded in this line table. */ >> +#define LINEMAPS_MACRO_HIGHEST_LOCATION(SET) \ >> + LINEMAPS_HIGHEST_LOCATION(SET, true) >> + >> +/* Returns the location of the begining of the highest line >> + -- containing a token resulting from macro expansion -- encoded >> + in the line table SET. */ >> +#define LINEMAPS_MACRO_HIGHEST_LINE(SET) \ >> + LINEMAPS_HIGHEST_LINE(SET, true) > > What is the use of these? The ordinary highest line/location are used > for various things, but I can't think of a reason you would want the > above, nor are they used in any of the patches. The former is necessary because locations yielded by original macro maps grow from zero to upward while locations yielded by macro maps grow from a MAX_SOURCE_LOCATION downward. As locations of macro locations decrease monotonically we need LINEMAPS_MACRO_HIGHEST_LOCATION (used in linemap_enter_macro) for reasons that are similar to why we need LINEMAPS_ORDINARY_HIGHEST_LOCATION. I added LINEMAPS_MACRO_HIGHEST_LINE for symmetry, as we had LINEMAPS_ORDINARY_HIGHEST_LINE. It's also because at some point I thought that I'd need a function like linemap_position_for_column, but for macro locations. This could be useful to e.g, create source locations for macro tokens that we are re-constructing. E.g, to support macro locations with -fpreprocessed. I stepped my ambitions down for this first batch of patches and I forgot to remove this macro. I'll remove it from my local updated version of the patch. > Maybe these should be in line_maps instead of maps_info? I think the former should stay in maps_info as each type of map (macro and ordinary) need its own highest location. Jason Merrill writes: > On 07/16/2011 07:37 AM, Dodji Seketeli wrote: > Apart from the added declaration, these changes seem like unnecessary > churn; let's avoid reformatting unchanged comments and removing > "extern" from declarations that are correct as they are. I am cleaning up this in my local version of the patch. Thanks. -- Dodji