This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 3/7] Emit macro expansion related diagnostics
- From: Jason Merrill <jason at redhat dot com>
- To: Dodji Seketeli <dodji at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, tromey at redhat dot com, gdr at integrable-solutions dot net, joseph at codesourcery dot com, burnus at net-b dot de, charlet at act-europe dot fr, bonzini at gnu dot org
- Date: Sat, 17 Sep 2011 10:11:01 -0400
- Subject: Re: [PATCH 3/7] Emit macro expansion related diagnostics
- References: <1291979498-1604-1-git-send-email-dodji@redhat.com> <cover.1310812267.git.dodji@redhat.com> <cover.1310824120.git.dodji@redhat.com> <7ab852c58faea9efd81130c5a1ddc9e78b34bcc5.1310824121.git.dodji@redhat.com> <m38vr9yyyq.fsf@seketeli.org> <4E6E73F8.4030603@redhat.com> <m3mxe4ex9s.fsf@redhat.com>
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