http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48248
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-03-28
16:15:52 UTC ---
Ah, I can reproduce with those lines.
Apparently caused by my PR41445 fix.
To fix this, I think we should remember not just src_line, but also filename
in print variable in c-ppoutput.c. And, either we should avoid calling
do_line_change for avoid_paste resp. PREV_WHITE in scan_translation_unit if
file is different, or maybe_print_line should do the
if (src_line >= print.src_line && src_line < print.src_line + 8)
optimization only if it is the same file.
As PR41445 has been in already in 4.5 and nobody complained about e.g.
# 1 "pr48248-2.C"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "pr48248-2.C"
# 1 "pr48248.h" 1
enum E { B };
# 2 "pr48248-2.C" 2
# 17 "pr48248-2.C"
void
foo ()
{
(void)
# 3 "pr48248.h"
B
# 20 "pr48248-2.C"
;
a;
}
(where # 3 "pr48248.h" doesn't say that the header is being entered, just
temporarily jumps to it), I'd probably prefer the latter choice, as it gives
more correct locus info.
