From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29145 invoked by alias); 19 Sep 2011 20:57:58 -0000 Received: (qmail 29128 invoked by uid 22791); 19 Sep 2011 20:57:56 -0000 X-SWARE-Spam-Status: No, hits=-6.7 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, 19 Sep 2011 20:57:37 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8JKvAfS014395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Sep 2011 16:57:11 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p8JKv9wK031596; Mon, 19 Sep 2011 16:57:09 -0400 Received: from [0.0.0.0] (ovpn-113-145.phx2.redhat.com [10.3.113.145]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p8JKv68H000557; Mon, 19 Sep 2011 16:57:06 -0400 Message-ID: <4E77ACA1.80205@redhat.com> Date: Mon, 19 Sep 2011 21:27:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 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, bonzini@gnu.org Subject: Re: [PATCH 3/7] Emit macro expansion related diagnostics References: <1291979498-1604-1-git-send-email-dodji@redhat.com> <7ab852c58faea9efd81130c5a1ddc9e78b34bcc5.1310824121.git.dodji@redhat.com> <4E6E73F8.4030603@redhat.com> <4E74AA75.8090106@redhat.com> <4E778A26.1000707@redhat.com> In-Reply-To: <4E778A26.1000707@redhat.com> Content-Type: text/plain; charset=UTF-8; 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-09/txt/msg01112.txt.bz2 On 09/19/2011 02:29 PM, Jason Merrill wrote: > expansion location. So it seems like we ought to be able to get away > with only storing one location per token in a macro expansion map. Am I > missing something? I notice that here: > + /* Resolve the location iter->where into the locus 1/ of the > + comment above. */ > + resolved_def_loc = > + linemap_resolve_location (line_table, iter->where, > + LRK_MACRO_PARM_REPLACEMENT_POINT, NULL); > + > + /* Resolve the location of the expansion point of the macro > + which expansion gave the token represented by def_loc. > + This is the locus 2/ of the earlier comment. */ > + resolved_exp_loc = > + linemap_resolve_location (line_table, > + MACRO_MAP_EXPANSION_POINT_LOCATION (iter->map), > + LRK_MACRO_PARM_REPLACEMENT_POINT, NULL); You're using LRK_MACRO_PARM_REPLACEMENT_POINT in both places for printing (and thus the second of the two token locations), whereas you used the first location in the unwinding process. It is sounding to me like the first location (xI) gets you the next virtual location in the unwinding process, whereas the second location (yI) gets you the spelling location of the token in the definition of a macro. Certainly all the calls to tokens_buff_add_token pass src->src_loc for the second. So why don't we look up the second location in the macro definition when we need it rather than store a copy in the map? Jason