From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) by sourceware.org (Postfix) with ESMTPS id A6DFD3857C6D for ; Mon, 11 Jul 2022 21:17:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A6DFD3857C6D Received: by mail-qv1-xf2f.google.com with SMTP id mi10so1288835qvb.1 for ; Mon, 11 Jul 2022 14:17:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=S+SuzOtMyXtACJrr7o2qy4g3VNWpHZzwXT22V2cl6Ls=; b=Q2JnxuqfFzB4EVuj417sc1TGmO74jJJqwzEGmFiVch+5n6Lu+LFWJ5zalaPFQYjEJz 7GC4m9VCrG1VHh4ZcnPUFcv06UHktqlLYYE/h6fUocfDS1L0JgR9nVtaHG/lN6NoTXfu SM+x3YCdhMSqEm7/b4gn5P3zO6smonmMWIvIbr9Srm2uizexAhnn9PbLD8w02iBUVqd6 L1KpQ+A8I+0uUkXHIGGHZJTuqfhaRWFWErt2W3jGtGxudY2wkzPdUCipfABclaG99gw+ pUOasXnsGWhpCFyLfdTZ7jzzPb0VD48FPLk/9dC1jao+v0PdwZBoOaa3iuEarug97DFx F+kQ== X-Gm-Message-State: AJIora9rAHlzHU9F3e5ORgkfyJCI7dg6YoFkC5ycavK754K/Sng9CWk7 d7wTeCp2Az6QQuUkbb2/a23hf7wr8Zc= X-Google-Smtp-Source: AGRyM1tptdm3BO80r3ni599/t2jALAgB+49ScZlfbZhWohJ2MYpMNl6fu5iRLl+nk7/UgBjlr4nD7A== X-Received: by 2002:a05:6214:2a8a:b0:472:ef2d:4fe3 with SMTP id jr10-20020a0562142a8a00b00472ef2d4fe3mr15236504qvb.47.1657574242577; Mon, 11 Jul 2022 14:17:22 -0700 (PDT) Received: from ldh-imac.local (96-67-140-173-static.hfc.comcastbusiness.net. [96.67.140.173]) by smtp.gmail.com with ESMTPSA id n16-20020a05622a041000b00304fe5247bfsm6391138qtx.36.2022.07.11.14.17.20 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 Jul 2022 14:17:21 -0700 (PDT) Date: Mon, 11 Jul 2022 17:17:19 -0400 From: Lewis Hyatt To: gcc-patches@gcc.gnu.org Subject: [PATCH] preprocessor: Set input_location to the most recently seen token Message-ID: <20220711211719.GA61164@ldh-imac.local> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline X-Spam-Status: No, score=-3039.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2022 21:17:26 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello- As discussed here: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598136.html Here is another short patch that improves "#pragma GCC diagnostic" handling. Longer term, it will be desirable to make the handling of this pragma independent of the global input_location. But in the meantime, some glitches like this one can be readily addressed by making input_location point to something better. In this case, input_location during preprocessing (-E or -save-temps) is made to point to the most recently seen token rather than the beginning of the file. To the best of my knowledge, nothing else besides "#pragma GCC diagnostic" handling can observe input_location during token streaming, so this is expected not to have any other repercussions. Bootstrap + regtest does look clean on x86-64 Linux. By the way, the new testcase fails when compiled with C++, but it's not because of pragma handling, it's rather because the C++ frontend changes the location on the warning to the wrong place. Once done_lexing has been set to true, it changes the location of all warnings to input_location, however that's not correct when the location is the cached location of a macro definition; the original location is preferable. I will file a separate PR about that, and have xfailed that testcase for now, since I am not quite there with grokking the reason it behaves this way, and anyway it's not related to this 1-line fix for gcc -E. Please let me know how it looks? Thanks! -Lewis --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline; filename="input_location_-E.txt" [PATCH] preprocessor: Set input_location to the most recently seen token When preprocessing with -E and -save-temps, input_location points always to the first character of the current file. This was previously irrelevant because nothing was called during the token streaming process that would inspect input_location. But since r13-1544, "#pragma GCC diagnostic" is supported in preprocess-only mode, and that pragma relies on input_location to decide if a given source code location is subject to a diagnostic or not. Most diagnostics work fine anyway, because they are handled as soon as they are seen and so everything is still seen in the expected order even though all the diagnostic pragmas are treated as if they applied at the start of the file. One example that doesn't work correctly is the new testcase, since here the warning is not triggered until the end of the file and so it is necessary to track the location properly. Fixed by setting input_location to point to each token as it is being streamed, similar to how C++ mode sets it. gcc/c-family/ChangeLog: * c-ppoutput.cc (token_streamer::stream): Update input_location prior to streaming each token. gcc/testsuite/ChangeLog: * c-c++-common/pragma-diag-14.c: New test. * c-c++-common/pragma-diag-15.c: New test. diff --git a/gcc/c-family/c-ppoutput.cc b/gcc/c-family/c-ppoutput.cc index cd38c969ea0..98081ccfbb0 100644 --- a/gcc/c-family/c-ppoutput.cc +++ b/gcc/c-family/c-ppoutput.cc @@ -210,6 +210,10 @@ void token_streamer::stream (cpp_reader *pfile, const cpp_token *token, location_t loc) { + /* Keep input_location up to date, since it is needed for processing early + pragmas such as #pragma GCC diagnostic. */ + input_location = loc; + if (token->type == CPP_PADDING) { avoid_paste = true; diff --git a/gcc/testsuite/c-c++-common/pragma-diag-14.c b/gcc/testsuite/c-c++-common/pragma-diag-14.c new file mode 100644 index 00000000000..618e7e1ef27 --- /dev/null +++ b/gcc/testsuite/c-c++-common/pragma-diag-14.c @@ -0,0 +1,9 @@ +/* { dg-do preprocess } */ +/* { dg-additional-options "-Wunused-macros" } */ + +/* In the past, the pragma has erroneously disabled the warning because the + location was not tracked properly with -E or -save-temps; check that it works + now. */ + +#define X /* { dg-warning "-:-Wunused-macros" } */ +#pragma GCC diagnostic ignored "-Wunused-macros" diff --git a/gcc/testsuite/c-c++-common/pragma-diag-15.c b/gcc/testsuite/c-c++-common/pragma-diag-15.c new file mode 100644 index 00000000000..d8076b4f93a --- /dev/null +++ b/gcc/testsuite/c-c++-common/pragma-diag-15.c @@ -0,0 +1,13 @@ +/* { dg-do compile } */ +/* { dg-additional-options "-Wunused-macros" } */ + +/* In the past, the pragma has erroneously disabled the warning because the + location was not tracked properly with -E or -save-temps; check that it works + now. + + This test currently fails for C++ but it's not because of the pragma, it's + because the location of the macro definition is incorrectly set. This is a + separate issue, will resolve it in a later patch. */ + +#define X /* { dg-warning "-:-Wunused-macros" {} { xfail c++ } } */ +#pragma GCC diagnostic ignored "-Wunused-macros" --tKW2IUtsqtDRztdT--