From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4569 invoked by alias); 17 Sep 2011 18:16:12 -0000 Received: (qmail 4557 invoked by uid 22791); 17 Sep 2011 18:16:12 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,DATE_IN_PAST_03_06,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; Sat, 17 Sep 2011 18:15:53 +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 p8HIFRvL026565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 17 Sep 2011 14:15:27 -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 p8HIFPUi015268; Sat, 17 Sep 2011 14:15:25 -0400 Received: from [0.0.0.0] (ovpn-113-36.phx2.redhat.com [10.3.113.36]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p8HIFLkX022635; Sat, 17 Sep 2011 14:15:22 -0400 Message-ID: <4E74AA75.8090106@redhat.com> Date: Sat, 17 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> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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/msg01024.txt.bz2 On 09/16/2011 03:55 AM, Dodji Seketeli wrote: > + test.c: In function ‘g’: > + test.c:5:14: error: invalid operands to binary << (have ‘double’ and ‘int’) > + 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 > + > + The part that goes from the third to the sixth line of this > + diagnostic (the lines containing the 'note:' string) is called the > + unwound macro expansion trace. That's the part generated by this > + function. No UTF-8 in the code, please. Do you mean eighth rather than sixth? > + /* If the token at RESOLVED_LOCATION [at macro definition point] > + is itself inside an expanded macro then we keep unwinding the > + trace by reaching the "parent macro" that got expanded inside > + the definition of the macro of MAP... */ This doesn't make sense to me; a macro definition can't be inside an expanded macro. Can you describe this situation better? > + if (first_exp_point_map) > + *first_exp_point_map = map; > + > + /* Walk LOC_VEC and print the macro expansion trace, unless the > + first macro which expansion triggered this trace was expanded > + inside a system header. */ > + if (!LINEMAP_SYSP (resolved_map)) Should the SYSP check use "map" rather than "resolved_map"? Jason