https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72803
--- Comment #6 from Aldy Hernandez <aldyh at gcc dot gnu.org> ---
In cp_lexer_new_main() we read all the tokens from the preprocessor:
/* Get the remaining tokens from the preprocessor. */
while (token.type != CPP_EOF)
{
cp_lexer_get_preprocessor_token (lexer, &token);
vec_safe_push (lexer->buffer, token);
}
The next to last token we push onto lexer->buffer is the closing brace in the
testcase:
(gdb) p token
$252 = {type = CPP_CLOSE_BRACE, keyword = RID_MAX, flags = 1 '\001',
implicit_extern_c = 0, error_reported = 0, purged_p = 0, location = 258432, u
= {
tree_check_value = 0x0, value = <tree 0x0>}}
(gdb) p token.location
$253 = 258432
(gdb) call expand_location($253)
$254 = {file = 0x7fffffffe774 "b.ii", line = 1, column = 511, data = 0x0, sysp
= false}
However, the next token is the CPP_EOF, and calling expand_location() again on
the CPP_CLOSE_BRACE token has the line and column offset completely incorrect:
// Read the next token, which is CPP_EOF
(gdb) next
(gdb) p token
$255 = {type = CPP_EOF, keyword = RID_MAX, flags = 64 '@', implicit_extern_c =
0,
error_reported = 0, purged_p = 0, location = 258496, u = {tree_check_value =
0x0,
value = <tree 0x0>}}
// Look at the closing brace token again:
(gdb) call expand_location($253)
$256 = {file = 0x7fffffffe774 "b.ii", line = 4, column = 127, data = 0x0, sysp
= false}
(gdb)
That should still be line 1 and column 511. Why is it line 4 and column 127?
Something smells fishy.
