[Bug c++/53431] New: C++ preprocessor ignores #pragma GCC diagnostic ignored "-Wundef"

[Bug c++/53431] New: C++ preprocessor ignores #pragma GCC diagnostic ignored "-Wundef"

[ml.lattuada at libero dot it]

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

             Bug #: 53431
           Summary: C++ preprocessor ignores #pragma GCC diagnostic
                    ignored "-Wundef"
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: minor
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: ml.lattuada@libero.it


The following code:

#pragma GCC diagnostic ignored "-Wundef"
#if FOO
#endif
int main (void) { return 42; }

compiled with 

g++ -o test test.c -Wundef -Werror

gives:

test.c:2:5: error: "FOO" is not defined [-Werror=undef]
cc1plus: all warnings being treated as errors

On the contrary

gcc -o test test.c -Wundef -Werror

does not give any error
gcc version is
gcc (Debian 4.7.0-8) 4.7.0

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored "-Wundef"

[rainarchitect at gmail dot com]

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

George Galeev <rainarchitect at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rainarchitect at gmail dot
                   |                            |com

--- Comment #1 from George Galeev <rainarchitect at gmail dot com> 2013-02-17 17:04:16 UTC ---
Same behavior, gcc-4.6.3, Linux gentoo x86-64

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored "-Wundef"

[markus at oberhumer dot com]

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

Markus F.X.J. Oberhumer <markus at oberhumer dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |markus at oberhumer dot com

--- Comment #2 from Markus F.X.J. Oberhumer <markus at oberhumer dot com> 2013-03-03 04:09:42 UTC ---
Still NOT fixed in gcc-4.8-20130210.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored "-Wundef"

[nomegenerico at email dot it]

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

Fabio <nomegenerico at email dot it> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nomegenerico at email dot it

--- Comment #3 from Fabio <nomegenerico at email dot it> ---
Same BUG in MinGW (version shipped with the Qt5.1 framework)

> gcc --version
gcc (rev2, Built by MinGW-builds project) 4.8.0
Copyright (C) 2013 Free Software Foundation, Inc.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored "-Wundef"

[rainarchitect at gmail dot com]

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

--- Comment #4 from George Galeev <rainarchitect at gmail dot com> ---
Guys, how to get a look at this bug? I'm tired of reading 100500 warnings from
third-party libraries.

GCC-4.6, GCC-4.7, GCC-4.8, C++11
Gentoo Linux x86-64

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored "-Wundef"

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-16
                 CC|                            |manu at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
The C++ parser lexes (and preprocesses) before handling the pragmas, whereas
the C parser processes the pragmas as it sees them.

We must somehow parse these pragmas *also* in cp/parser.c:631. Maybe one can do
something similar to what we do for cp_parser_initial_pragma, but within the
loop and only handling pragma diagnostic. Surely, it will need some trial and
error to get it right. If any of you wants to give it a try and need some help,
just ask here or in the mailing list.
>From gcc-bugs-return-434764-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 16 19:58:25 2013
Return-Path: <gcc-bugs-return-434764-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 16808 invoked by alias); 16 Nov 2013 19:58:25 -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 16769 invoked by uid 48); 16 Nov 2013 19:58:21 -0000
From: "mikpelinux at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/59139] [4.7/4.8/4.9 Regression] internal compiler error: in get_val_for, at tree-ssa-loop-niter.c:2267
Date: Sat, 16 Nov 2013 19:58: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:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mikpelinux at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-59139-4-wBqk5ydAIb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59139-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59139-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: 2013-11/txt/msg01541.txt.bz2
Content-length: 414

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY139

Mikael Pettersson <mikpelinux at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikpelinux at gmail dot com

--- Comment #2 from Mikael Pettersson <mikpelinux at gmail dot com> ---
Started with r173612.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored "-Wundef"

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |scottbaldwin at gmail dot com

--- Comment #6 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
*** Bug 57241 has been marked as a duplicate of this bug. ***
>From gcc-bugs-return-434770-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Nov 16 20:23:15 2013
Return-Path: <gcc-bugs-return-434770-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 26835 invoked by alias); 16 Nov 2013 20:23:15 -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 26677 invoked by uid 48); 16 Nov 2013 20:23:11 -0000
From: "glisse at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug inline-asm/59157] New: "+f" constraint rejected: output constraint 0 must specify a single register
Date: Sat, 16 Nov 2013 20:23:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: inline-asm
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: glisse at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cf_gcctarget
Message-ID: <bug-59157-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: 2013-11/txt/msg01547.txt.bz2
Content-length: 755

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY157

            Bug ID: 59157
           Summary: "+f" constraint rejected: output constraint 0 must
                    specify a single register
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: inline-asm
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glisse at gcc dot gnu.org
            Target: x86_64-unknown-linux-gnu

double f(double x){
  asm volatile("":"+f"(x));
  return x;
}

a.c: In function 'f':
a.c:2:3: error: output constraint 0 must specify a single register
   asm volatile("":"+f"(x));
   ^

If I use "+mf", it is accepted with -m64 but still fails with -m32.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[manu at gcc dot gnu.org]

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

--- Comment #9 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #5)
> The C++ parser lexes (and preprocesses) before handling the pragmas, whereas
> the C parser processes the pragmas as it sees them.
> 
> We must somehow parse these pragmas *also* in cp/parser.c:631. Maybe one can
> do something similar to what we do for cp_parser_initial_pragma, but within
> the loop and only handling pragma diagnostic. Surely, it will need some
> trial and error to get it right. If any of you wants to give it a try and
> need some help, just ask here or in the mailing list.

There are two problems that need fixing to implement this:

1. At the point the pragma is lexed we don't know that this is pragma GCC
diagnostic, since the pragmas are registered dynamically and there is no (enum
pragma_kind) PRAGMA_GCC_DIAGNOSTIC. Perhaps one could do what is done for
PRAGMA_GCC_PCH_PREPROCESS.

2. The second problem is that handle_pragma_diagnostic does not work during
lexing (at least for C++). We would need to rewrite the whole function and call
it directly.
>From gcc-bugs-return-461319-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Sep 05 17:57:46 2014
Return-Path: <gcc-bugs-return-461319-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25263 invoked by alias); 5 Sep 2014 17:57:45 -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 25226 invoked by uid 48); 5 Sep 2014 17:57:42 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug bootstrap/63188] [5 Regression] r214954 breaks bootstrap on x86_64-apple-darwin13
Date: Fri, 05 Sep 2014 17:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: bootstrap
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: blocker
X-Bugzilla-Who: dominiq at lps dot ens.fr
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-63188-4-F8aQNeVrXy@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63188-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63188-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-09/txt/msg01153.txt.bz2
Content-length: 555

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

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Bootstrap of revision r214972 with the patch

--- ../_clean/gcc/config/darwin.h    2014-06-27 18:25:13.000000000 +0200
+++ gcc/config/darwin.h    2014-09-05 18:28:29.000000000 +0200
@@ -499,7 +499,7 @@ extern GTY(()) int darwin_ms_struct;
 #define NO_PROFILE_COUNTERS    1

 #undef    INIT_SECTION_ASM_OP
-#define INIT_SECTION_ASM_OP
+#define INIT_SECTION_ASM_OP ""

 #undef    INVOKE__main

just completed, testing in progress.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
Created attachment 35688
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35688&action=edit
WIP patch

A WIP patch. I took a different approach: Move the handling of the pragma to
the preprocessor. 

It is a bit ugly, but the problem is that we cannot access diagnostic.h and
similar headers from the preprocessor. In my ideal world, we would have a
libdiagnostic.a that can be linked to the preprocessor and the FEs, and avoid
those callbacks (if someone wants to implement a different diagnostic output,
they can simply implement a basic libdiagnostic.a).

The main problem I didn't know how to solve is that, once processed, the
preprocessor removes the pragmas. Ideally, the pragmas should be evaluated when
lexing, independently of whether the file is preprocessed or not. Otherwise, it
will break things like ccache.
>From gcc-bugs-return-487934-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Jun 03 08:27:44 2015
Return-Path: <gcc-bugs-return-487934-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 74478 invoked by alias); 3 Jun 2015 08:27:44 -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 74029 invoked by uid 48); 3 Jun 2015 08:27:39 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/64223] same warning repeated twice with same line number
Date: Wed, 03 Jun 2015 08:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.8.3
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: mpolacek at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-64223-4-URlmbFKNfL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64223-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64223-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: 2015-06/txt/msg00266.txt.bz2
Content-length: 438

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #7 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Should be fixed.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[manu at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 3561 bytes --]

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

--- Comment #12 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Allan Chandler from comment #11)
> Now you've done it. This was reported over three years ago and now it's
> affected someone on Stack Overflow. You guys are in for it now :-)

Unfortunately, the C/C++ FEs in GCC have very very few developers relative to
their importance and amount work they require. There is a patch in comment #10,
but it requires some additional work for which I do not have enough free time.
If you or someone else has some free time to finish this work, this is how I
would proceed:

1. Try to figure out why the preprocessor removes the pragmas (and not other
#-directives)
2. If you cannot figure it out, ask in gcc@ with explicit CC to C/C++/libcpp
maintainers (see MAINTAINERS file).
3. Complete the patch, bootstrap&regression test, add a Changelog, submit to
gcc-patches and ping until it is approved.

More details:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

Otherwise, given that this hasn't been fixed in more than 4 years (see
PR48914), it seems likely that active developers have higher priority things to
work on and it will remain unfixed until some new volunteer steps up to the
task.

If/When I have a little free time to work on GCC, there are at least a couple
of other bugs I would rather fix before this one.
>From gcc-bugs-return-492817-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jul 20 09:40:31 2015
Return-Path: <gcc-bugs-return-492817-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 117016 invoked by alias); 20 Jul 2015 09:40:31 -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 116717 invoked by uid 48); 20 Jul 2015 09:40:27 -0000
From: "ktkachov at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/66915] [6 Regression] FAIL: gcc.dg/fixed-point/unary.c execution test on arm
Date: Mon, 20 Jul 2015 09:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: ktkachov at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: attachments.created
Message-ID: <bug-66915-4-XvakCBXVjI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66915-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66915-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: 2015-07/txt/msg01707.txt.bz2
Content-length: 252

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Created attachment 36015
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id6015&actioníit
Diff between good and bad versions of the assembly

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[noloader at gmail dot com]

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

--- Comment #13 from Jeffrey Walton <noloader at gmail dot com> ---
This issued caused Crypto++ to remove -Wall (and above) under GCC. Crypto++ is
C++ with lots of interfaces, and it performs a fair amount of intermediate
calculations used in an assert. It really needed the following to work as
expected:

// GCC diagnostcs available after GCC 4.2
(https://gcc.gnu.org/ml/gcc-help/2015-07/msg00063.html)
#define GCC_DIAGNOSTIC_AWARE ((__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__
>= 2)) || defined(__clang__))

#if GCC_DIAGNOSTIC_AWARE
# pragma GCC diagnostic push
# pragma GCC diagnostic ignored "-Wunused-value"
# pragma GCC diagnostic ignored "-Wunused-variable"
#endif

Crypto++ is fortunate in that its multi-compiler friendly and cross-platform.
It can use Clang, ICC, Comeau or, say MSVC with /W4. Other projects are not so
lucky. They include Asterisk (the PBX software package). Asterisk uses
trampolines, so it cannot compile under Clang. And it never supported MSVC.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[redi at gcc dot gnu.org]

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

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jeffrey Walton from comment #13)
> This issued caused Crypto++ to remove -Wall (and above) under GCC.

That seems to be throwing the baby out with the bathwater. Why not simply use

 -Wall -Wno-unused-value -Wno-unused-variable

?

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[noloader at gmail dot com]

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

--- Comment #16 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Jeffrey Walton from comment #13)
> > This issued caused Crypto++ to remove -Wall (and above) under GCC.
> 
> That seems to be throwing the baby out with the bathwater.

Yeah, for us its a calculated risk. We had other compilers available that
worked as expected, so we could lower the bar for GCC. The residual risk is the
set of issues GCC will catch minus the set of issues the other compilers will
catch. Hopefully, the set is the empty set.

> Why not simply use
> 
>  -Wall -Wno-unused-value -Wno-unused-variable
> 
We don't want to pollute the command line.

All in all, the best solution for us from a usability and engineering
standpoint is to have the GCC diagnostic block work as advertised. Then, we
manage our warnings in our headers and source code through the GCC block, and
they don't cross pollinate into the user's code.

And the users of the library do not need to worry about disabling warnings on
the command line. Without GCC diagnostic blocks, users of the library must
guess at what needs to be on the command line when compiling and linking
against the library. And then they wonder why we did not take the time to clear
or silence the warning.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[noloader at gmail dot com]

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

--- Comment #17 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Jonathan Wakely from comment #15)
> (In reply to Jeffrey Walton from comment #13)
> > This issued caused Crypto++ to remove -Wall (and above) under GCC.
> 
> That seems to be throwing the baby out with the bathwater. Why not simply use
> 
>  -Wall -Wno-unused-value -Wno-unused-variable
> 

Here's a concrete example that just hit my inbox:
https://groups.google.com/d/msg/cryptopp-users/ixwCeessWZ8/xR2eOC3-j0MJ.

Its a user who compiling/linking against the library. We can't control what
options he puts on the command line. But he will discuss a noisy compile :)

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[redi at gcc dot gnu.org]

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

--- Comment #18 from Jonathan Wakely <redi at gcc dot gnu.org> ---
You can't control what warnings users enable, but that's no reason not to use
-Wall -Wno-unused yourself when building cryptopp. Not polluting you command
line seems like a weak excuse given the pollution in the code to support
compilers from last millennium (which I know you're getting rid of) and the
pollution that loads of compiler-specific pragmas cause.

The -Wno-xxx options exist, today, and they work, and even if this bug is fixed
it isn't going to be fixed in GCC 4.x or 5.x so the pragmas won't be a complete
solution for many years until noone uses today's compilers.

Or you could just change the code causing the warnings.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[manu at gcc dot gnu.org]

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

--- Comment #19 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
For what is worth, anyone please feel free to take my WIP patch in comment #10
and get it finished. You may also claim for yourself any bounty or compensation
that may derive from it.
>From gcc-bugs-return-493099-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 23 11:59:30 2015
Return-Path: <gcc-bugs-return-493099-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 86947 invoked by alias); 23 Jul 2015 11:59:30 -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 86454 invoked by uid 48); 23 Jul 2015 11:59:26 -0000
From: "noloader at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
Date: Thu, 23 Jul 2015 11:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: noloader at gmail dot com
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:
Message-ID: <bug-53431-4-CgJt1HSbXW@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53431-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53431-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: 2015-07/txt/msg01989.txt.bz2
Content-length: 492

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

--- Comment #20 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #19)
> For what is worth, anyone please feel free to take my WIP patch in comment
> #10 and get it finished. You may also claim for yourself any bounty or
> compensation that may derive from it.

Or, let me know where you would like a donation made (I've found the FOSS folks
often don't due it for money).
>From gcc-bugs-return-493100-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 23 12:01:12 2015
Return-Path: <gcc-bugs-return-493100-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 91680 invoked by alias); 23 Jul 2015 12:01:11 -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 91614 invoked by uid 48); 23 Jul 2015 12:01:07 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/52987] bogus expected ; before for undeclared type
Date: Thu, 23 Jul 2015 12:01:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: FIXED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution target_milestone
Message-ID: <bug-52987-4-d25y1FVHRm@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-52987-4@http.gcc.gnu.org/bugzilla/>
References: <bug-52987-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: 2015-07/txt/msg01990.txt.bz2
Content-length: 489

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED
   Target Milestone|---                         |6.0

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Fixed.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[manu at gcc dot gnu.org]

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

--- Comment #23 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #21)
> Now that you posted a complete example here:
> https://gcc.gnu.org/ml/gcc-help/2015-07/msg00070.html you seem to actually
> be hitting PR66290, not this one.

Sorry, I meant PR64079.
>From gcc-bugs-return-493108-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 23 13:31:13 2015
Return-Path: <gcc-bugs-return-493108-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 63052 invoked by alias); 23 Jul 2015 13:31:13 -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 62998 invoked by uid 48); 23 Jul 2015 13:31:09 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/64079] %+D in diagnostics breaks pragma GCC diagnostic
Date: Thu, 23 Jul 2015 13:31:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords: diagnostic, easyhack
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: keywords
Message-ID: <bug-64079-4-NZvnnx0Au6@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64079-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64079-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: 2015-07/txt/msg01998.txt.bz2
Content-length: 513

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |easyhack

--- Comment #4 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
BTW, changes like the above are trivial to implement and test, thus this is a
nice easy-hack for beginners.
>From gcc-bugs-return-493109-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 23 13:40:23 2015
Return-Path: <gcc-bugs-return-493109-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 126183 invoked by alias); 23 Jul 2015 13:40:23 -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 126120 invoked by uid 48); 23 Jul 2015 13:40:14 -0000
From: "noloader at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
Date: Thu, 23 Jul 2015 13:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: noloader at gmail dot com
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:
Message-ID: <bug-53431-4-01lcM5piiJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-53431-4@http.gcc.gnu.org/bugzilla/>
References: <bug-53431-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: 2015-07/txt/msg01999.txt.bz2
Content-length: 558

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

--- Comment #24 from Jeffrey Walton <noloader at gmail dot com> ---
(In reply to Manuel López-Ibáñez from comment #23)
> (In reply to Manuel López-Ibáñez from comment #21)
> > Now that you posted a complete example here:
> > https://gcc.gnu.org/ml/gcc-help/2015-07/msg00070.html you seem to actually
> > be hitting PR66290, not this one.
> 
> Sorry, I meant PR64079.

NP. In that example I posted, I meant GCC_DIAGNOSTIC_AWARE, not
GCC_OPTIMIZE_AWARE. Sorry about that.
>From gcc-bugs-return-493110-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 23 13:45:00 2015
Return-Path: <gcc-bugs-return-493110-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 5047 invoked by alias); 23 Jul 2015 13:45:00 -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 4635 invoked by uid 48); 23 Jul 2015 13:44:55 -0000
From: "olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/66930] [5 Regression]: gengtype.c is miscompiled during stage2
Date: Thu, 23 Jul 2015 13:45:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.2.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: olegendo at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-66930-4-58Get96sdV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-66930-4@http.gcc.gnu.org/bugzilla/>
References: <bug-66930-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: 2015-07/txt/msg02000.txt.bz2
Content-length: 3821

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

--- Comment #10 from Oleg Endo <olegendo at gcc dot gnu.org> ---
(In reply to Kazumoto Kojima from comment #6)
> Created attachment 36040 [details]
> .i file for gengtype.c
> 
> I've confirmed a miscompile for gengtype.c with -O1 on my 5/6
> compilers.  With them,
> 
>      if (union_p)
>        {
> 	 oprintf (d->of, "%*sbreak;\n", d->indent, "");
> 	 d->indent -= 2;
>        }
> 
> lines in gengtype.c:walk_type function are compiled like as:
> 
>         bf      .L2253
>         mov.l   .L2593,r7
>         mov.l   @(36,r12),r6
>         mov.l   .L2580,r5
>         mov.l   .L2595,r1
>         jsr     @r1
> 	...
> 
> i.e. the instruction testing union_p variable is removed.
> The resulted gengtype produces files without "break" in many
> cases.  Although it's the other way around with the reported
> full of "break" symptom, I think the both are the same issue.
> The deletion has happened in sh_split_movrt_negc_to_movt_xor
> which is called by movrt_negc insn_and_split.  It seems that
> that splitting is applied for the case
> 
> 	tst	reg,reg
> 	mov	#-1,reg1
> 	negc	reg1,reg1
>         ...
>         call ...
>         ...
> 	tst	reg,reg
> 
> and the last tst was removed.  Oleg, could you take a look into
> this?

Somehow I couldn't find the code patterns above in my version of the compiled
code, so I've compared the compiled asm code of gengtype.ii with
sh_split_movrt_negc_to_movt_xor and without (always returns false) at -O1 and
hit this diff:

without:
        mov.l   @(40,r15),r0
        cmp/eq  #5,r0
        mov     #-1,r0
        negc    r0,r0
        mov.b   r0,@(2,r8)
        mov     r12,r5
        mov.l   .L2664,r1
        jsr     @r1
        mov.l   @(8,r10),r4
        mov     r14,r0
        mov.b   r0,@(2,r8)
        mov.l   .L2631,r1
        jsr     @r1
        mov     r13,r4
        mov.l   @(40,r15),r0
        cmp/eq  #5,r0
        bf      .L2286

with:
        mov.l   @(44,r15),r0
        cmp/eq  #5,r0
        movt    r0
        xor     #1,r0
        mov.b   r0,@(2,r8)
        mov     r12,r5
        mov.l   .L2664,r1
        jsr     @r1
        mov.l   @(8,r10),r4
        mov     r14,r0
        mov.b   r0,@(2,r8)
        mov.l   .L2631,r1
        jsr     @r1
        mov     r13,r4
        bf      .L2286

The original idea of this transformation is to not clobber the T bit with the
negc-movrt insn and re-use the T bit later.  It seems that it's missing the
fact that the T bit is clobbered by calls.  The following seems to fix it:

Index: gcc/config/sh/sh.c
===================================================================
--- gcc/config/sh/sh.c  (revision 225987)
+++ gcc/config/sh/sh.c  (working copy)
@@ -13888,6 +13888,7 @@
       && !sh_insn_operands_modified_between_p (t_before_negc.insn,
                                               t_before_negc.insn,
                                               t_after_negc.insn)
+      && !modified_between_p (get_t_reg_rtx (), curr_insn, t_after_negc.insn)
       && !sh_unspec_insn_p (t_after_negc.insn)
       && !volatile_insn_p (PATTERN (t_after_negc.insn))
       && !side_effects_p (PATTERN (t_after_negc.insn))

I've added this code as part of PR 63986.  I've checked with make -k check-gcc
RUNTESTFLAGS="sh.exp --target_board=sh-sim\{-m2a/-mb,-m4/-ml,-m4/-mb}" that
there are no new SH specific fails, so I assume the patch above should be OK
(although all the checks should probably be combined to avoid walking the insns
repeatedly).  Could you please add it to your test run?  I'm sorry for this
nasty bug.  Obviously it's not only a problem for -O1 but for anything > -O0.
>From gcc-bugs-return-493111-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jul 23 13:47:46 2015
Return-Path: <gcc-bugs-return-493111-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29596 invoked by alias); 23 Jul 2015 13:47:46 -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 29455 invoked by uid 48); 23 Jul 2015 13:47:42 -0000
From: "anders.granlund.0 at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/66976] New: Compiler error for well-formed program with a definition of a constexpr function returning void
Date: Thu, 23 Jul 2015 13:47:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: anders.granlund.0 at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-66976-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: 2015-07/txt/msg02001.txt.bz2
Content-length: 6034

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

            Bug ID: 66976
           Summary: Compiler error for well-formed program with a
                    definition of a constexpr function returning void
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: anders.granlund.0 at gmail dot com
  Target Milestone: ---

The following program (prog.cc in the command line below) is well-formed:

  constexpr void f() {}
  int main() {}

Note that the return type void is a literal type according to [basic.types]/10:

  http://eel.is/c++draft/basic.types#10

I compiled the program with the following command line:

  gcc prog.cc -std=c++11 -pedantic-errors

I expected to get no errors since the program is well-formed, but I got the
following error:

prog.cc: In function 'constexpr void f()':
prog.cc:1:16: error: invalid return type 'void' of constexpr function
'constexpr void f()'constexpr void f() {}
                ^

For comparison Clang accepts the program without errors.

Output for gcc -v (I think the bug quite independent of this however):

Using built-in specs.
COLLECT_GCC=/usr/local/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/heads/gcc/gcc-source/configure
--prefix=/usr/local/gcc-head --enable-languages=c,c++ --enable-lto
--disable-multilib --without-ppl --without-cloog-ppl --enable-checking=release
--disable-nls
Thread model: posix
gcc version 6.0.0 20150722 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-std=c++11' '-pedantic-errors' '-v'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/cc1plus -quiet
-v -imultiarch x86_64-linux-gnu -D_GNU_SOURCE prog.cc -quiet -dumpbase prog.cc
-mtune=generic -march=x86-64 -auxbase prog -pedantic-errors -std=c++11 -version
-o /tmp/ccE6wwKW.s
GNU C++11 (GCC) version 6.0.0 20150722 (experimental)
(x86_64-unknown-linux-gnu)
        compiled by GNU C version 6.0.0 20150722 (experimental), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
warning: GMP header version 5.1.2 differs from library version 5.0.2.
warning: MPFR header version 3.1.2 differs from library version 3.1.0-p3.
GGC heuristics: --param ggc-min-expand\x100 --param ggc-min-heapsize\x131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0

/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0/x86_64-unknown-linux-gnu

/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../include/c++/6.0.0/backward
 /usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/include
 /usr/local/include
 /usr/local/gcc-head/include
 /usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C++11 (GCC) version 6.0.0 20150722 (experimental)
(x86_64-unknown-linux-gnu)
        compiled by GNU C version 6.0.0 20150722 (experimental), GMP version
5.1.2, MPFR version 3.1.2, MPC version 1.0.1
warning: GMP header version 5.1.2 differs from library version 5.0.2.
warning: MPFR header version 3.1.2 differs from library version 3.1.0-p3.
GGC heuristics: --param ggc-min-expand\x100 --param ggc-min-heapsize\x131072
Compiler executable checksum: 9115218d8690e08d2bbd8844106c0d12
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-std=c++11' '-pedantic-errors' '-v'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/cc8TSYhs.o /tmp/ccE6wwKW.s
GNU assembler version 2.22 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.22
COMPILER_PATH=/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/:/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/:/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/:/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/:/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/
LIBRARY_PATH=/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/:/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../lib64/:/lib/x86_64-linux-gnu/:/lib/../lib64/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib64/:/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-std=c++11' '-pedantic-errors' '-v'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/collect2
-plugin
/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/liblto_plugin.so
-plugin-opt=/usr/local/gcc-head/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/cc4yk1QX.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc
--eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
prog.exe /usr/lib/x86_64-linux-gnu/crt1.o /usr/lib/x86_64-linux-gnu/crti.o
/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/crtbegin.o
-L/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0
-L/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../../../lib64
-L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/../lib64
-L/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/../../.. -rpath
/usr/local/gcc-head/lib64 -lpthread /tmp/cc8TSYhs.o -lstdc++ -lm -lgcc_s -lgcc
-lc -lgcc_s -lgcc
/usr/local/gcc-head/lib/gcc/x86_64-unknown-linux-gnu/6.0.0/crtend.o
/usr/lib/x86_64-linux-gnu/crtn.o

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[noloader at gmail dot com]

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

--- Comment #25 from Jeffrey Walton <noloader at gmail dot com> ---
Jonathan, Manuel, et al -

I'm putting this to bed on our side. We've re-enabled -Wall, and are moving
towards -Wextra.

I did come up with one more use case... The "unused parameter" warning.
Typically, I just comment it out:

   int Foo(int /*bar*/);

However, when generating documentation from sources, that's not a good
strategy. I now see the program omits the parameter altogether from the markup.

In the case of Crypto++, which has a lot of "interface programming" aspects, it
makes for a noisy compile as objects are composed and derived. There's often no
way to avoid something being unused along the inheritance chain.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev <miyuki at gcc dot gnu.org> changed:

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

--- Comment #26 from Mikhail Maltsev <miyuki at gcc dot gnu.org> ---
Probably, you could use __attribute__((unused)) as a workaround. Some wrapper
macro can make it less verbose, e.g. like here:

https://github.com/gcc-mirror/gcc/blob/master/include/ansidecl.h#L157
https://github.com/gcc-mirror/gcc/blob/master/gcc/c-family/c-common.c#L6980

You can then add "ARG_UNUSED(x)=x" (or "__attribute__(x)=") to PREDEFINED
parameter of your doxygen config (you did not mention the documentation system,
but doxygen is used on cryptopp.com).

I.e. in your code you'll have:
int Foo(int ARG_UNUSED(bar));

the compiler will see it as:
int Foo(int bar __attribute__((unused)));

and doxygen (and other compilers, if you tweak the macro a bit) as:
int Foo(int bar);

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[noloader at gmail dot com]

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

--- Comment #40 from Jeffrey Walton <noloader at gmail dot com> ---
Still a problem in 2021.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

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

--- Comment #41 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 100891 has been marked as a duplicate of this bug. ***

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #42 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
#pragma GCC diagnostic is handled in the FEs when it sees the pragmas among
tokens it gets from the preprocessor.
So, for diagnostics emitted from the preprocessor, it depends on how to FE uses
the preprocessor.  The C++ FE preprocesses everything into a long array of
tokens and then parses that, so no GCC diagnostic pragmas can affect any
diagnostics from the preprocessor.
The C FE uses the preprocessor whenever it needs another token, has a 2 token
look-ahead if needed but in certain cases can grab far more tokens from the
preprocessor and store them for later use (see c_parser_peek_nth_token_raw
etc.).
So, unless it does that (which is currently used mostly for [[]] attributes or
some OpenMP constructs) and when the usual 2 token look-ahead likely doesn't
cross the diagnostic pragma that needs to be parsed, GCC diagnostic likely
works for C most of the time.
I think if we want to make GCC diagnostic pragma work for C++ preprocessor
diagnostics, we'd need to either parse them also in the preprocessor and for
the options preprocessor cares about remember what it does, or when filling up
the large array of tokens in the C++ FE parse (silently?) the pragmas too,
invoke the  diagnostic APIs to ignore or promote to -Werror etc. as it goes,
and at the end when CPP_EOF is encountered reset the state to the start at the
start of the compilation.
Doing separate parsing in the preprocessor would have an advantage that it
would
also affect -E, which currently isn't affected for either C or C++ I think,
but due to the way C FE works would need need separate warning state for
preprocessor diagnostics and for the FE diagnostics.
Doing it in the C++ FE would be easier, but -E would ignore them.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[egallager at gcc dot gnu.org]

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

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |allan.chandler at oakton dot com.a
                   |                            |u, damien at iwi dot me,
                   |                            |dietmar.schindler@manroland
                   |                            |goss.com,
                   |                            |dmalcolm at gcc dot gnu.org,
                   |                            |marco.lattuada at polimi dot it,
                   |                            |max at maxbruckner dot de,
                   |                            |miyuki at gcc dot gnu.org,
                   |                            |mpolacek at gcc dot gnu.org,
                   |                            |rainarchitect at gmail dot com,
                   |                            |robert.simpson.lists@gmail.
                   |                            |com,
                   |                            |ruslan_baratov at yahoo dot com,
                   |                            |scottbaldwin at gmail dot com,
                   |                            |TrevorJamesHickey at gmail dot com
                   |                            |, ulidtko at gmail dot com,
                   |                            |_hamlet at libero dot it

--- Comment #43 from Eric Gallager <egallager at gcc dot gnu.org> ---
Came up again about the new -Wbidi-chars option here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585777.html 

(I'm also taking this time to re-add some CCs that got lost without being
listed as being removed in the bug history, presumably due to server migration)

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[lhyatt at gcc dot gnu.org]

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

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

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

--- Comment #44 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
I have a patch for this submitted to the mailing list here:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/586191.html

Initially I tried resurrecting Manuel's patch from comment #10 and got it
working, however it led to other issues for C++. The problem is that, with that
change, the C++ frontend processes the pragmas too early, instead of too late;
it processes every #pragma GCC diagnostic in the file prior to handling any
tokens. This makes a large demand on the diagnostics infrastructure, namely
that it correctly handles every case of processing source lines and determining
which #pragmas are in effect at that time and which are for the future. This
infrastructure is in place and generally works, however it doesn't handle all
cases, notably a change to the argument of an option (say something like,
#pragma GCC diagnostic warning "-Wimplicit-fallthrough=4") is not tracked
properly (see also PR c/71603). The state of warning options is also often
queried directly by the frontend code, not making use of the diagnostics state
tracking facilities, and this also leads to warnings being generated or not
generated unexpectedly. So this patch leads to a lot of testcase failures, for
example, c-c++-common/Wshadow-1.c.

I think in the ideal case, it should be made to work correctly that all
diagnostic pragmas could be parsed prior to processing the tokens and
everything would work, but this seems like a large overhaul. I can try to
tackle improving that later, but for the purpose of resolving this PR, I
thought it was worth trying another approach, which is just to arrange that
every frontend does
indeed handle the #pragma when it needs to. My patch does things this way, it
adds the concept of an early pragma handler, which can be registered similar to
a normal one and runs in addition to it. The early handler for diagnostic
pragmas then filters for libcpp-generated diagnostics and processes those when
called. Then the C++ frontend, and gcc -E, are both modified to make use of it.
This asks much less of the state tracking, since only libcpp diagnostics are
handled early.

The C++ frontend changes are not too extensive, it basically notes when it sees
a CPP_PRAGMA_EOL token during initial parsing, and if so, it handles it
immediately. In order to reuse the existing handler for diagnostic pragmas, it
sets up the main lexer so that it is sufficiently prepared for pragma_lex() to
work, which is all that is needed.

For preprocessing mode, I needed to refactor the code for
handle_diagnostic_pragma a bit, since in preprocess-only mode, there is no C or
C++ parser available and the tokens need to be lexed directly from libcpp. I
also needed adjustments in c-ppoutput.c to make sure, as Manuel pointed out,
that we do still output the #pragma GCC diagnostic in the preprocessed output.

I hope this looks workable, happy to adjust the patch as needed.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |lh_mouse at 126 dot com

--- Comment #45 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 91932 has been marked as a duplicate of this bug. ***

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[manu at gcc dot gnu.org]

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

--- Comment #46 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Lewis Hyatt from comment #44)
> I hope this looks workable, happy to adjust the patch as needed.

If you don't get much attention to the patch, it may be worth pinging it. But
before that, I would also suggest submitting all the cleanups separately as
their own, easy-to-review patch. For example, the bits about
cp_token_is_module_directive.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[lhyatt at gcc dot gnu.org]

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

--- Comment #47 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
(In reply to Manuel López-Ibáñez from comment #46)
> If you don't get much attention to the patch, it may be worth pinging it.
> But before that, I would also suggest submitting all the cleanups separately
> as their own, easy-to-review patch. For example, the bits about
> cp_token_is_module_directive.

Thank you for the note, I have resubmitted it to gcc-patches in two parts:
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587357.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587358.html

The cp_token_is_module_directive that you highlighted clearly should be in its
own patch, yes. I looked through the rest though and wasn't able to identify
anything else that seemed to make sense when split out on its own, so that
ended up being the only thing I factored out.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andre.schackier at gmail dot com

--- Comment #48 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 105020 has been marked as a duplicate of this bug. ***

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[lhyatt at gcc dot gnu.org]

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

--- Comment #49 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
I rebased the patches so they apply to the current master branch and pinged
them on gcc-patches here:
https://gcc.gnu.org/pipermail/gcc-patches/2022-May/595556.html

-Lewis

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[lhyatt at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gcc at behdad dot org

--- Comment #50 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
*** Bug 100125 has been marked as a duplicate of this bug. ***

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[cvs-commit at gcc dot gnu.org]

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

--- Comment #51 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:e46f4d7430c5210465791603735ab219ef263c51

commit r13-1544-ge46f4d7430c5210465791603735ab219ef263c51
Author: Lewis Hyatt <lhyatt@gmail.com>
Date:   Tue Jul 5 17:15:28 2022 -0400

    diagnostics: Honor #pragma GCC diagnostic in the preprocessor [PR53431]

    As discussed on PR c++/53431, currently, "#pragma GCC diagnostic" does
    not always take effect for diagnostics generated by libcpp. The reason
    is that libcpp itself does not interpret this pragma and only sends it on
    to the frontend, hence the pragma is only honored if the frontend
    arranges for it. The C frontend does process the pragma immediately
    (more or less) after seeing the token, so things work fine there. The PR
    points out that it doesn't work for C++, because the C++ frontend
    doesn't handle anything until it has read all the tokens from
    libcpp. The underlying problem is not C++-specific, though, and for
    instance, gcc -E has the same issue.

    This commit fixes the PR by adding the concept of an early pragma handler
that
    can be registered by frontends, which gives them a chance to process
    diagnostic pragmas from libcpp before it is too late for them to take
    effect. The C++ and preprocess-only frontends are modified to use early
    pragmas and correct the behavior.

    gcc/c-family/ChangeLog:

            PR preprocessor/53920
            PR c++/53431
            * c-common.cc (c_option_is_from_cpp_diagnostics): New function.
            * c-common.h (c_option_is_from_cpp_diagnostics): Declare.
            (c_pp_stream_token): Declare.
            * c-ppoutput.cc (init_pp_output): Refactor logic about skipping
            pragmas to...
            (should_output_pragmas): ...here. New function.
            (token_streamer::stream): Support handling early pragmas.
            (do_line_change): Likewise.
            (c_pp_stream_token): New function.
            * c-pragma.cc (struct pragma_diagnostic_data): New helper class.
            (pragma_diagnostic_lex_normal): New function. Moved logic for
            interpreting GCC diagnostic pragmas here.
            (pragma_diagnostic_lex_pp): New function for parsing diagnostic
pragmas
            directly from libcpp.
            (handle_pragma_diagnostic): Refactor into helper function...
            (handle_pragma_diagnostic_impl): ...here.  New function.
            (handle_pragma_diagnostic_early): New function.
            (handle_pragma_diagnostic_early_pp): New function.
            (struct pragma_ns_name): Renamed to...
            (struct pragma_pp_data): ...this.  Add new "early_handler" member.
            (c_register_pragma_1): Support early pragmas in the preprocessor.
            (c_register_pragma_with_early_handler): New function.
            (c_register_pragma): Support the new early handlers in struct
            internal_pragma_handler.
            (c_register_pragma_with_data): Likewise.
            (c_register_pragma_with_expansion): Likewise.
            (c_register_pragma_with_expansion_and_data): Likewise.
            (c_invoke_early_pragma_handler): New function.
            (c_pp_invoke_early_pragma_handler): New function.
            (init_pragma): Add early pragma support for diagnostic pragmas.
            * c-pragma.h (struct internal_pragma_handler): Add new early
handler
            members.
            (c_register_pragma_with_early_handler): Declare.
            (c_invoke_early_pragma_handler): Declare.
            (c_pp_invoke_early_pragma_handler): Declare.

    gcc/cp/ChangeLog:

            PR c++/53431
            * parser.cc (cp_parser_pragma_kind): Move earlier in the file.
            (cp_lexer_handle_early_pragma): New function.
            (cp_lexer_new_main): Support parsing and handling early pragmas.
            (c_parse_file): Adapt to changes in cp_lexer_new_main.

    gcc/testsuite/ChangeLog:

            PR preprocessor/53920
            PR c++/53431
            * c-c++-common/pragma-diag-11.c: New test.
            * c-c++-common/pragma-diag-12.c: New test.
            * c-c++-common/pragma-diag-13.c: New test.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[lhyatt at gcc dot gnu.org]

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

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

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

--- Comment #52 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
Fixed for GCC 13.

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[lhyatt at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |f.heckenbach@fh-soft.de

--- Comment #53 from Lewis Hyatt <lhyatt at gcc dot gnu.org> ---
*** Bug 91037 has been marked as a duplicate of this bug. ***

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.0

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[markus at oberhumer dot com]

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

--- Comment #54 from Markus F.X.J. Oberhumer <markus at oberhumer dot com> ---
Many thanks for finally fixing this!