From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3286 invoked by alias); 2 Aug 2011 04:48:31 -0000 Received: (qmail 3276 invoked by uid 22791); 2 Aug 2011 04:48:30 -0000 X-SWARE-Spam-Status: No, hits=-6.8 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; Tue, 02 Aug 2011 04:48:13 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p724lgvH012179 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Aug 2011 00:47:42 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p724le4R002794; Tue, 2 Aug 2011 00:47:40 -0400 Received: from [0.0.0.0] ([10.3.113.4]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p724la0r005475; Tue, 2 Aug 2011 00:47:37 -0400 Message-ID: <4E378168.2090903@redhat.com> Date: Tue, 02 Aug 2011 04:48:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux i686; rv:5.0) Gecko/20110719 Thunderbird/5.0 MIME-Version: 1.0 To: Dodji Seketeli 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> In-Reply-To: <3d6fbfd16f0e3493839205de1266eaaa8dbb9c77.1310824121.git.dodji@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00099.txt.bz2 On 07/16/2011 10:37 AM, Dodji Seketeli wrote: > 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. Ah, I see, I was missing the use in linemap_enter_macro. But then it's really LINEMAPS_MACRO_LOWEST_LOCATION, isn't it? :) And I think you don't really need it: since we know exactly how many tokens a macro map has when we create it, you could just put the lower bound in start_location and index upward from there so we don't need LOCATION_POSSIBLY_IN_MAP_P (which is a strange name for an ordering predicate). > + bool expand_to_expansion_point_p = > + !linemap_tracks_macro_expansion_locs_p (line_table); > + > + /* If LOC is the location of a token resulting from macro > + expansion, either expand to the location of the macro expansion > + point if we don't support tracking token locations accross > + macro expansion, or expand to the actual spelling location of > + the token where the error is if we do support tracking > + locations accross macro expansion. */ > + xloc = > + linemap_expand_location_full (line_table, loc, > + (expand_to_expansion_point_p) > + ? LRK_MACRO_EXPANSION_POINT > + : LRK_SPELLING_LOCATION, > + NULL); Why is this logic here? It seems like it would be better to just pass LRK_SPELLING_LOCATION and have linemap_expand_location_full do the best it can. Also, in light of: > * include/line-map.h (linemap_expand_location_full): Add an output > parameter returning the spelling location the input location got > resolved to, at declaration point ... > * line-map.c (linemap_expand_location_full): ... and at definition > point. it seems like what you really want is two functions, one that resolves one location to another, and a different function that just expands the result. > + This map shall be created when the macro is expanded. The map > + encodes the source location of the expansion point of the macro as > + well as the "original" source location of each token that is part > + of the macro replacement-list. If a macro is defined but never Hmm. The locations of the tokens in the macro definition are shared between all expansions of a particular macro, so I wonder if it would be possible to encode only the information about the actual macro invocation, i.e. the expansion point and the locations of the argument tokens. That ought to be smaller than repeating all the macro token locations. > + ORIG_LOC is the orginal location of the token at the definition > + point of the macro. If you read the extensive comments of struct > + line_map_macro in line-map.h, this is the xI. > + If the token is part of a macro argument, ORIG_PARM_REPLACEMENT_LOC > + is the location of the point at wich the token (the argument) > + replaces the macro parameter in the context of the relevant macro > + definition. If you read the comments of struct line_map_macro in > + line-map.h, this is the yI. */ I continue to find this description confusing. In: > + int a = PLUS (1,2); <--- #2 Which of these is the location of "1"? I'd think it would be an xI, but that isn't in the definition of a macro. Jason