3600218c8b
Consider the test case gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c. Its interesting part is: #define A(x) vari x /* line 7. */ #define vari(x) #define B , varj int A(B) ; /* line 10. */ In its initial version, this test was being pre-processed as: # 1 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c" # 1 "build/gcc//" # 1 "<command-line>" # 1 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c" # 10 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c" int # 7 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c" vari , varj ; Note how "int" and "vari" are on separate lines, whereas "int" and ", varj" are on the same line. This looks like a bug to me, even independantly from the macro location tracking work. With macro location tracking turned on, the preprocessed output becomes: # 1 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c" # 1 "<command-line>" # 1 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c" # 10 "gcc/testsuite/gcc.dg/debug/dwarf2/pr41445-5.c" int vari , varj ; Which, IMO, is what we'd expect. This is due to an unexpected side effect of enter_macro_context when passed a token that might look like a function-like macro at first sight, but that it eventually considers to not be a macro after all. This is the case for the "vari" token which looks like a macro when it is first lexed, but is eventually considered to be a normal token by enter_macro_context because it's not used as a function-like macro invocation. In that case, besides returning NULL, enter_macro_context sets pfile->context->c.macro to NULL, making cpp_get_token_1 forget to set the location of the "vari" to the expansion point of A. enter_macro_context sets pfile->context->c.macro to NULL in that case because funlike_invocation_p reads one token pass "foo", sees that there is no '(' token, so we are not invoking the function-like parameter. It then puts the tokens (which it has read after "foo") back into the tokens stream by calling _cpp_push_token_context on it, which sets pfile->context->c.macro to NULL, saying in essence that the current macro expansion context is "stopped". The fix here is to teach _cpp_push_token and push_extended_tokens_context to continue the current macro context when passed a NULL macro. But then, now that there can be several continguous contexts associated with the same macro, we need to teach _cpp_pop_context to re-enable the expansion of the current macro only when we are really out of expanding the current macro. Otherwise we can run in cases where we have recursive expansions of the same macro. Tested on x86_64-unknown-linux-gnu against trunk. Now this test has the same output with and without tracking locations accross macro expansions. Note that the bootstrap with -ftrack-macro-expansion exhibits other separate issues that are addressed in subsequent patches. This patch just fixes one class of problems. The patch does pass bootstrap with -ftrack-macro-expansion turned off, though. libcpp/ * macro.c (macro_of_context): New static function. (_cpp_push_token_context, push_extended_tokens_context): If the macro argument is NULL, it means we are continuing the expansion of the current macro, if any. Update comments. (_cpp_pop_context): Re-enable expansion of the macro only when we are really out of the context of the current expansion. gcc/testsuite/ * gcc.dg/debug/dwarf2/pr41445-5.c: Adjust. * gcc.dg/debug/dwarf2/pr41445-6.c: Likewise. From-SVN: r186968 |
||
---|---|---|
.. | ||
include | ||
po | ||
aclocal.m4 | ||
ChangeLog | ||
charset.c | ||
config.in | ||
configure | ||
configure.ac | ||
directives-only.c | ||
directives.c | ||
errors.c | ||
expr.c | ||
files.c | ||
identifiers.c | ||
init.c | ||
internal.h | ||
lex.c | ||
line-map.c | ||
macro.c | ||
Makefile.in | ||
makeucnid.c | ||
mkdeps.c | ||
pch.c | ||
symtab.c | ||
system.h | ||
traditional.c | ||
ucnid.h | ||
ucnid.tab |