From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13279 invoked by alias); 19 Jul 2011 09:43:14 -0000 Received: (qmail 13268 invoked by uid 22791); 19 Jul 2011 09:43:13 -0000 X-SWARE-Spam-Status: No, hits=-6.4 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, 19 Jul 2011 09:42:54 +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 p6J9gOkw015499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 19 Jul 2011 05:42:24 -0400 Received: from localhost (ovpn-113-141.phx2.redhat.com [10.3.113.141]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p6J9gL8R009717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Jul 2011 05:42:22 -0400 Received: by localhost (Postfix, from userid 500) id 9FF7929C049; Tue, 19 Jul 2011 11:42:20 +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, bonzini@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> <4E249A5C.9060409@redhat.com> X-URL: http://www.redhat.com Date: Tue, 19 Jul 2011 10:47:00 -0000 In-Reply-To: <4E249A5C.9060409@redhat.com> (Jason Merrill's message of "Mon, 18 Jul 2011 16:41:00 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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-07/txt/msg01489.txt.bz2 Jason Merrill writes: > On 07/16/2011 10:37 AM, Dodji Seketeli wrote: >> + /* This array of location is actually an array of pairs of >> + locations. The elements inside it thus look like: >> + >> + x0,y0, x1,y1, x2,y2, ...., xn,yn. > > Pairs of locations still seems limited, given the flexibility of macro > expansion; with macros that use other macros a particular token can be > substituted an arbitrary number of times; the first time doesn't seem > particularly special. If you are talking about the case of a macro A that can have (among the tokens of its replacement list) a token B that itself is a macro, then this is supported by the current setup. When A goes through its expansion process it's replaced by the tokens of its replacement list. The B (like all the other tokens of the replacement list of A) token is allocated a virtual location that encodes the {xi,yi} pair, yes. But that virtual location of B also encodes the location of the expansion point of B, which is not stored in the line_map_macro::macro_locations you are talking about here. It is stored in the line_map_macro::expansion. Then when B goes through its expansion process, the same process of virtual location allocation happens, recursively. > > But then, it seems that nothing uses the replacement point > currently. The diagnostics mentioned in patch 3 only seem to use the > spelling location and the expansion location: > >> [dodji@adjoa gcc]$ ./cc1 -quiet -ftrack-macro-expansion test.c >> test.c: In function =E2=80=98g=E2=80=99: >> test.c:5:14: erreur: invalid operands to binary << (have =E2=80=98double= =E2=80=99 and =E2=80=98int=E2=80=99) >> test.c:2:9: note: in expansion of macro 'OPERATE' >> test.c:5:3: note: expanded from here >> test.c:5:14: note: in expansion of macro 'SHIFTL' >> test.c:8:3: note: expanded from here >> test.c:8:3: note: in expansion of macro 'MULT2' >> test.c:13:3: note: expanded from here > > So how do you expect to use the replacement point information? In that example, this diagnostic test.c:2:9: note: in expansion of macro 'OPERATE' actually uses the replacement point information. It's just that it's not obvious because the token on which the error happens is not an argument of a function-like macro. Consider this example instead: $ cat -n test11.c=20 1 int var; 2 #define S(x) 1 + x 3 int foo (void) 4 { 5 return S( 2 + var() + 3); 6 } $ ./cc1 -ftrack-macro-expansion -quiet ../../prtests/test11.c test11.c: In function =E2=80=98foo=E2=80=99: test11.c:5:20: erreur: called object =E2=80=98var=E2=80=99 is not a function test11.c:2:18: note: in expansion of macro 'S' test11.c:5:10: note: expanded from here $=20 In this example, the error happens on the 'var' token which is passed as an argument to the S function-like macro. And we want to point, in the definition of S, to the location where the 'var' argument token is used. That's the 2:18 location referred to by the line: test11.c:2:18: note: in expansion of macro 'S' --=20 Dodji