[Bug c/60014] New: Bad warning suppression

[Bug c/60014] New: Bad warning suppression

[megahallon at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014

            Bug ID: 60014
           Summary: Bad warning suppression
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: megahallon at gmail dot com

Using gcc 4.8.2:

/tmp/foo/foo.h:
-------------------------------
#define FOO(a, b) __LINE__;
-------------------------------

bug.c:
-------------------------------
#include "foo.h"

int main()
{
  FOO(1, 
      0);
  char* a = 1;
}
-------------------------------

$ /usr/bin/gcc bug.c -isystem /tmp/foo -no-integrated-cpp

should give a warning on line 7 but it not seen.

These works:

$ /usr/bin/gcc bug.c -isystem /tmp/foo -no-integrated-cpp
-ftrack-macro-expansion=0
$ /usr/bin/gcc bug.c -I /tmp/foo -no-integrated-cpp
$ /usr/bin/gcc bug.c -isystem /tmp/foo

-save-temps gives the same results as -no-integrated-cpp.

Output from -save-temps:

bug.i
-----------------------------
void main()
{

 6
# 5 "bug.c" 3 4
  ;
        ;
  char *a = 1;
}
-----------------------------

The suppress flag in the line directive apparently affects line 7 which is not
as expected.

In practice this means that ccache and similar systems that compiles
preprocessed output may fail to show warnings that are seen when compiling
normally.

[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp

[peff at peff dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014

Jeff King <peff at peff dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |peff at peff dot net

--- Comment #2 from Jeff King <peff at peff dot net> ---
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

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014

Manuel López-Ibáñez <manu at gcc dot gnu.org> 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 <manu at gcc dot gnu.org> ---
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 "<built-in>"
# 1 "<command-line>"
# 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 "<built-in>"
# 1 "<command-line>"
# 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;
}
>From gcc-bugs-return-453607-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 10 10:25:02 2014
Return-Path: <gcc-bugs-return-453607-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16513 invoked by alias); 10 Jun 2014 10:25:02 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 16442 invoked by uid 48); 10 Jun 2014 10:24:55 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.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: Tue, 10 Jun 2014 10:25:00 -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:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
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:
Message-ID: <bug-60014-4-vlSPQzjvSL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-60014-4@http.gcc.gnu.org/bugzilla/>
References: <bug-60014-4@http.gcc.gnu.org/bugzilla/>
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
X-SW-Source: 2014-06/txt/msg00689.txt.bz2
Content-length: 263

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
The meaning of the flags is given here:
https://gcc.gnu.org/onlinedocs/cpp/Preprocessor-Output.html#Preprocessor-Output
>From gcc-bugs-return-453608-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Jun 10 10:30:22 2014
Return-Path: <gcc-bugs-return-453608-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 21260 invoked by alias); 10 Jun 2014 10:30:21 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 21196 invoked by uid 55); 10 Jun 2014 10:30:18 -0000
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/57186] implement load sinking in loops
Date: Tue, 10 Jun 2014 10:30:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: NEW
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:
Message-ID: <bug-57186-4-yy1RYrKcrT@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57186-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57186-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-06/txt/msg00690.txt.bz2
Content-length: 625

https://gcc.gnu.org/bugzilla/show_bug.cgi?idW186

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Tue Jun 10 10:29:44 2014
New Revision: 211404

URL: http://gcc.gnu.org/viewcvs?rev!1404&root=gcc&view=rev
Log:
2014-06-10  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/57186
    PR tree-optimization/59299
    * gcc.dg/tree-ssa/ssa-sink-11.c: New testcase.
    * gcc.dg/tree-ssa/ssa-sink-12.c: Likewise.

Added:
    trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-11.c
    trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-12.c
Modified:
    trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp

[megahallon at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014

--- Comment #5 from Fredrik Hallenberg <megahallon at gmail dot com> ---
Same results with gcc 5.1.0.

[Bug preprocessor/60014] Bad warning suppression caused by track-macro-expansion when not using integrated cpp

[lhyatt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014

Lewis Hyatt <lhyatt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lhyatt at gcc dot gnu.org

--- Comment #8 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014

--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Lewis Hyatt <lhyatt@gcc.gnu.org>:

https://gcc.gnu.org/g:ddb7f0a0cac48762ba6408d69538f8115c4a2739

commit r13-3264-gddb7f0a0cac48762ba6408d69538f8115c4a2739
Author: Lewis Hyatt <lhyatt@gmail.com>
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

[lhyatt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60014

Lewis Hyatt <lhyatt at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
The underlying issue is fixed for GCC 13 now.