From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7F9C53858C62; Thu, 6 Oct 2022 21:51:53 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7F9C53858C62 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1665093113; bh=OVHu+FuYPbm+1HP2dXBJ98HtZaeOeHqij/C5+7fBXfs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZZ49MMjerpWdvG37gTLdknezLIgHLB8Y5B0tyZsa1jSwvB6z/MEp/oJDuv43/qpsy dGQ0gKWVMaFPt/eu78GkResRnaOyE0JJ0Jd5MZCo2TYwe7gOJATiIJ0MT8MJx0zgND rUPRZ74f0C6oOe4gnYkrD0aqY0ezvCrZcJSXnnU4= From: "lhyatt at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp Date: Thu, 06 Oct 2022 21:51:52 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: preprocessor X-Bugzilla-Version: 4.8.2 X-Bugzilla-Keywords: diagnostic, easyhack X-Bugzilla-Severity: normal X-Bugzilla-Who: lhyatt at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D60014 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 ma= cro __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 t= he 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, Manu= el's point still stands, c-ppoutput.cc should not have behaved this way, even ab= sent r9-1926. The problem is that here: =3D=3D=3D=3D=3D=3D if (do_line_adjustments && !in_pragma && !line_marker_emitted && print.prev_was_system_token !=3D !!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 =3D !!in_system_header_at (loc); } =3D=3D=3D=3D=3D=3D=3D 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 assump= tion 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: =3D=3D=3D=3D=3D=3D $ cat t2.h #pragma GCC system_header #define X _Pragma("GCC diagnostic push"); $ cat t2.c #include "./t2.h" X const char* should_warn =3D 1; $ gcc -Wint-conversion -c t2.c t2.c:3:27: warning: initialization of =E2=80=98const char *=E2=80=99 from = =E2=80=98int=E2=80=99 makes pointer from integer without a cast [-Wint-conversion] 3 | const char* should_warn =3D 1; | ^ $ gcc -Wint-conversion -c t2.c -save-temps $ =3D=3D=3D=3D=3D=3D I can test the fix and prepare a patch for that.=