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
