https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128241
--- Comment #1 from Moritz Baumann <moritz.baumann at sap dot com> --- I have been sitting on this problem and the failing test case for years now, but never found sufficient time to understand and debug the preprocessor. Since I was getting nowhere, I pointed an LLM at my test case and it came up with the following analysis: --- The bug is in paste_tokens() in libcpp/macro.cc (around line 1051). When ## token pasting is used in a macro and one of the operands is a multi-line raw string literal, the following happens: 1. paste_tokens spells out both operands (e.g., u + R"(\nsome\nmulti\nline\nliteral\n)") into a temporary buffer and pushes it onto the buffer stack (from_stage3 = true) 2. _cpp_lex_direct -> lex_raw_string is called on this synthetic buffer 3. For each embedded \n in the raw string, lex_raw_string calls CPP_INCREMENT_LINE (which advances pfile->line_table->highest_line) 4. When the temporary buffer is popped via _cpp_pop_buffer, it has no mechanism to undo those line table increments — highest_line is left permanently offset by N (where N = number of newlines in the raw string) This means every token after the macro expansion has its source location computed against a highest_line that's N lines too far ahead, producing wrong line numbers in warnings, errors, and debug info. --- I was able to verify the analysis by testing the change proposed by the LLM. Since I am not entirely sure whether the change counts as legally significant (according to the AI policy), I am only posting the above analysis for now. The LLM-generated change would insert 11 LOC in paste_tokens and the same number of explanatory comment lines. I can attach or submit the patch if desired.
