From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22807 invoked by alias); 19 Sep 2011 18:30:58 -0000 Received: (qmail 22797 invoked by uid 22791); 19 Sep 2011 18:30:57 -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 18:30:31 +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 p8JIU4rF013256 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 19 Sep 2011 14:30:05 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8JIU2Tv005462; Mon, 19 Sep 2011 14:30:03 -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 p8JITw82009378; Mon, 19 Sep 2011 14:29:59 -0400 Message-ID: <4E778A26.1000707@redhat.com> Date: Mon, 19 Sep 2011 19:47: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> In-Reply-To: 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/msg01105.txt.bz2 On 09/19/2011 09:58 AM, Dodji Seketeli wrote: > + The part that goes from the third to the heighth line of this An extra 'h' snuck in there. :) > Inside the definition of a macro M, you can have another macro M'. > And M' is going to be eventually expanded into a token FOO. > > So, to paraphrase what I said earlier, FOO [which is at a point in the > definition of the macro M] is itself inside the expanded macro M'. So what we're dealing with here is the token FOO. We start with its fully-expanded location, and then step out to see where it was expanded from. If that location is still within a macro expansion, we step out again until we are at the point in the source that originally triggered a macro expansion. Right? I don't understand how that unwinding operation maps onto a function called linemap_macro_map_loc_to_def_point, and why we need to use both that function and linemap_macro_map_loc_to_exp_point here. I'm afraid this is leading me to question the basic model again. > + 1 #define OPERATE(OPRD1, OPRT, OPRD2) \ > + 2 OPRD1 OPRT OPRD2; > + 3 > + 4 #define SHIFTL(A,B) \ > + 5 OPERATE (A,<<,B) > + 6 > + 7 #define MULT(A) \ > + 8 SHIFTL (A,1) > + 9 > + 10 void > + 11 g () > + 12 { > + 13 MULT (1.0);// 1.0 << 1; <-- so this is an error. > + 14 } Here "1.0" has the locations 2(OPRD1), 5(A), 8(A), 13(1.0). "<<" has the locations 2(OPRT), 5(<<), 8(SHIFTL), 13(MULT). Each token has 4 locations, one for each of the macros involved plus one for the original 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? Jason