[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014 Lewis Hyatt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Lewis Hyatt --- The underlying issue is fixed for GCC 13 now.
[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014 --- Comment #9 from CVS Commits --- The master branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:ddb7f0a0cac48762ba6408d69538f8115c4a2739 commit r13-3264-gddb7f0a0cac48762ba6408d69538f8115c4a2739 Author: Lewis Hyatt Date: Thu Oct 6 18:05:02 2022 -0400 preprocessor: Fix tracking of system header state [PR60014,PR60723] The token_streamer class (which implements gcc mode -E and -save-temps/-no-integrated-cpp) needs to keep track whether the last tokens output were in a system header, so that it can generate line marker annotations as necessary for a downstream consumer to reconstruct the state. The logic for tracking it, which was added by r5-1863 to resolve PR60723, has some edge case issues as revealed by the three new test cases. The first, coming from the original PR60014, was incidentally fixed by r9-1926 for unrelated reasons. The other two were still failing on master prior to this commit. Such code paths were not realizable prior to r13-1544, which made it possible for the token streamer to see CPP_PRAGMA tokens in more contexts. The two main issues being corrected here are: 1) print.prev_was_system_token needs to indicate whether the previous token output was in a system location. However, it was not being set on every token, only on those that triggered the main code path; specifically it was not triggered on a CPP_PRAGMA token. Testcase 2 covers this case. 2) The token_streamer uses a variable "line_marker_emitted" to remember whether a line marker has been emitted while processing a given token, so that it wouldn't be done more than once in case multiple conditions requiring a line marker are true. There was no reason for this to be a member variable that retains its value from token to token, since it is just needed for tracking the state locally while processing a single given token. The fact that it could retain its value for a subsequent token is rather difficult to observe, but testcase 3 demonstrates incorrect behavior resulting from that. Moving this to a local variable also simplifies understanding the control flow going forward. gcc/c-family/ChangeLog: PR preprocessor/60014 PR preprocessor/60723 * c-ppoutput.cc (class token_streamer): Remove member line_marker_emitted to... (token_streamer::stream): ...a local variable here. Set print.prev_was_system_token on all code paths. gcc/testsuite/ChangeLog: PR preprocessor/60014 PR preprocessor/60723 * gcc.dg/cpp/pr60014-1.c: New test. * gcc.dg/cpp/pr60014-1.h: New test. * gcc.dg/cpp/pr60014-2.c: New test. * gcc.dg/cpp/pr60014-2.h: New test. * gcc.dg/cpp/pr60014-3.c: New test. * gcc.dg/cpp/pr60014-3.h: New test.
[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #8 from Lewis Hyatt --- The testcase for this PR was one of many that got fixed by r9-1926 (for PR69558). The location of the token resulting from expanding the builtin macro __LINE__ was, prior to r9-1926, pointing to the closing paren of the macro invocation, i.e. not in the system header. After r9-1926, the location of the token is a virtual location encoding that the token resulted from expansion of a macro defined in a system header, and so the "system"-ness of the token no longer gets lost. Fredrik's original testcase is a nice one. Every element in it is essential to reveal the issue, including the extra semicolon in the FOO macro and the newline in the invocation. Although that testcase now works correctly, Manuel's point still stands, c-ppoutput.cc should not have behaved this way, even absent r9-1926. The problem is that here: == if (do_line_adjustments && !in_pragma && !line_marker_emitted && print.prev_was_system_token != !!in_system_header_at (loc) && !is_location_from_builtin_token (loc)) /* The system-ness of this token is different from the one of the previous token. Let's emit a line change to mark the new system-ness before we emit the token. */ { do_line_change (pfile, token, loc, false); print.prev_was_system_token = !!in_system_header_at (loc); } === print.prev_was_system_token should be set always, not only when the if statement is reached and evaluates to true. In this PR's testcase prior to r9-1926, the check evaluated to false when streaming the semicolon from the macro expansion, because a line marker had been printed due to the fact that the __LINE__ token and the semicolon were assigned locations on different lines. So the logic in c-ppoutput.cc assumes that you can never get two tokens on different lines without a line change callback, which is not a crazy assumption but was violated due to the issue fixed by r9-1926. However, there are other code paths besides the line change logic that can trigger the same issue still now. One way is to stream a deferred CPP_PRAGMA token, since that code path doesn't even execute the above if statement. As of r13-1544, we do see such tokens while preprocessing, so here is a modified testcase that fails on master: == $ cat t2.h #pragma GCC system_header #define X _Pragma("GCC diagnostic push"); $ cat t2.c #include "./t2.h" X const char* should_warn = 1; $ gcc -Wint-conversion -c t2.c t2.c:3:27: warning: initialization of ‘const char *’ from ‘int’ makes pointer from integer without a cast [-Wint-conversion] 3 | const char* should_warn = 1; | ^ $ gcc -Wint-conversion -c t2.c -save-temps $ == I can test the fix and prepare a patch for that.
[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014 Manuel López-Ibáñez changed: What|Removed |Added Keywords||diagnostic, easyhack Last reconfirmed|2014-06-10 00:00:00 |2016-6-23 --- Comment #7 from Manuel López-Ibáñez --- (In reply to Fredrik Hallenberg from comment #6) > Reconfirmed with gcc 6.1.1 I don't think anything will change until someone volunteers to debug and propose a fix: https://gcc.gnu.org/wiki/DebuggingGCC The problem is in c-family/c-ppoutput.c It seems print.prev_was_system_token is not always correctly updated. In particular, we may call do_line_change at various places and emit a sysp linemarker in print_line_1, but then not update print.prev_was_system_token. It only makes sense to update its value within this function, so it is synchronized with the corresponding linemarkers.
[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014 --- Comment #6 from Fredrik Hallenberg --- Reconfirmed with gcc 6.1.1
[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014 --- Comment #5 from Fredrik Hallenberg --- Same results with gcc 5.1.0.
[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014 --- Comment #4 from Manuel López-Ibáñez --- The meaning of the flags is given here: https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html#Preprocessor-Output
[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-06-10 CC||dodji at gcc dot gnu.org, ||manu at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Manuel López-Ibáñez --- I can reproduce it in trunk using: #pragma GCC system_header #define FOO(a, b) __LINE__; I think the problem is that there is a push of the system-header-ness flag on the expansion of the macro, but there is no pop to restore non-system-header-ness. That is, we generate: # 1 "test.c" # 1 "" # 1 "" # 1 "test.c" # 1 "test.h" 1 # 2 "test.h" 3 # 2 "test.c" 2 int main() { 6 # 5 "test.c" 3 ; ; char* a = 1; } but we should generate: # 1 "test.c" # 1 "" # 1 "" # 1 "test.c" # 1 "test.h" 1 # 2 "test.h" 3 # 2 "test.c" 2 int main() { 6 # 5 "test.c" 3 ; # 6 "test.c" ; char* a = 1; }
[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014 Jeff King changed: What|Removed |Added CC||peff at peff dot net --- Comment #2 from Jeff King --- I can confirm the problem here (as well as a real world case found while building git). I bisected and found that revision 186969 introduces the problem: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=186969
[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014 --- Comment #1 from Fredrik Hallenberg --- Same results with gcc 4.9.0