[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #54 from Markus F.X.J. Oberhumer --- Many thanks for finally fixing this!
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |13.0
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Lewis Hyatt changed: What|Removed |Added CC||f.heckenb...@fh-soft.de --- Comment #53 from Lewis Hyatt --- *** Bug 91037 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Lewis Hyatt changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #52 from Lewis Hyatt --- Fixed for GCC 13.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #51 from CVS Commits --- The master branch has been updated by Lewis Hyatt : https://gcc.gnu.org/g:e46f4d7430c5210465791603735ab219ef263c51 commit r13-1544-ge46f4d7430c5210465791603735ab219ef263c51 Author: Lewis Hyatt 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Lewis Hyatt changed: What|Removed |Added CC||gcc at behdad dot org --- Comment #50 from Lewis Hyatt --- *** Bug 100125 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #49 from Lewis Hyatt --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Andrew Pinski changed: What|Removed |Added CC||andre.schackier at gmail dot com --- Comment #48 from Andrew Pinski --- *** Bug 105020 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #47 from Lewis Hyatt --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #46 from Manuel López-Ibáñez --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Andrew Pinski changed: What|Removed |Added CC||lh_mouse at 126 dot com --- Comment #45 from Andrew Pinski --- *** Bug 91932 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Lewis Hyatt changed: What|Removed |Added CC||lhyatt at gcc dot gnu.org --- Comment #44 from Lewis Hyatt --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Eric Gallager 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 --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #42 from Jakub Jelinek --- #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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Jonathan Wakely changed: What|Removed |Added CC||tobi at gcc dot gnu.org --- Comment #41 from Jonathan Wakely --- *** Bug 100891 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #40 from Jeffrey Walton --- Still a problem in 2021.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #39 from Eric Gallager --- (In reply to Nickolay Kolchin-Semyonov from comment #38) > Since this is a long standing problem, maybe this limitation should be > mentioned in official documentation? Maybe... although, if documented, people might think current behavior is the intended behavior, when it isn't... I guess it depends on the wording used to do said documentation...
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #38 from Nickolay Kolchin-Semyonov --- Since this is a long standing problem, maybe this limitation should be mentioned in official documentation?
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #37 from Jonathan Wakely --- From PR 89806: Sample code: #pragma GCC diagnostic ignored "-Wdate-time" const char* g_test = "dirty-" __DATE__; When compiling with g++ (g++ -Werror=date-time) this produces: :2:31: error: macro "__DATE__" might prevent reproducible builds [-Werror=date-time] 2 | const char* g_test = "dirty-" __DATE__; | ^~~~ cc1plus: some warnings being treated as errors Compiler returned: 1 But with GCC this compiles without errors (gcc -Werror=date-time).
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Jonathan Wakely changed: What|Removed |Added CC||nbkolchin at gmail dot com --- Comment #36 from Jonathan Wakely --- *** Bug 89806 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Jonathan Wakely changed: What|Removed |Added CC||ulidtko at gmail dot com --- Comment #35 from Jonathan Wakely --- *** Bug 89038 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Robert J. Simpson changed: What|Removed |Added CC||robert.simpson.lists@gmail. ||com --- Comment #34 from Robert J. Simpson --- Appears to still be an issue in gcc-8: gcc 8.2.0 #pragma GCC diagnostic ignored "-Wcomment" // multi-line comment \ // ../canvas.cpp:85:1: warning: multi-line comment [-Wcomment] // multi-line comment \ ^
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Martin Sebor changed: What|Removed |Added CC||davydden at gmail dot com --- Comment #33 from Martin Sebor --- *** Bug 84127 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 sandra at gcc dot gnu.org changed: What|Removed |Added CC||sandra at gcc dot gnu.org --- Comment #32 from sandra at gcc dot gnu.org --- Here's another case which I think is the same bug, observed in GCC 7.2: #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wpedantic" #include_next #pragma GCC diagnostic pop does nothing to suppress the -Wpedantic warning about #include_next.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Manuel López-Ibáñez changed: What|Removed |Added CC||damien at iwi dot me --- Comment #31 from Manuel López-Ibáñez --- *** Bug 79701 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Manuel López-Ibáñez changed: What|Removed |Added CC||akim.demaille at gmail dot com --- Comment #30 from Manuel López-Ibáñez --- *** Bug 80650 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431
Hamlet <_hamlet at libero dot it> changed:
What|Removed |Added
CC||_hamlet at libero dot it
--- Comment #29 from Hamlet <_hamlet at libero dot it> ---
For what it's worth, I confirm this (and bug 70888) with gcc 6.3.0 from
Gentoo/Linux.
In particular, the following program ("test.cpp"):
#pragma GCC diagnostic ignored "-Wlong-long"
const unsigned long long int ticks_per_day = 864LL;
compiled with `g++-6.3.0 -c -std=c++03 -pedantic -Werror test.cpp` (C++03
standard) issues an error:
test.cpp:2:46: error: use of C++11 long long integer constant
[-Werror=long-long]
const unsigned long long int ticks_per_day = 864LL;
^
about the long long literal value, while it correctly suppresses the one about
the variable itself. Skipping the preprocessor (`-fpreprocessed`) does not
affect the outcome (the preprocessor correctly leaves the `#pragma` directive
untouched anyway).
Using `-Wno-long-long` in the command line instead works as expected (but it's
not a viable solution when dealing with third party libraries).
Info on GCC:
Using built-in specs.
COLLECT_GCC=gcc-6.3.0
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/6.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-6.3.0/work/gcc-6.3.0/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/6.3.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/6.3.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/6.3.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/6.3.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/6.3.0/include/g++-v6
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/6.3.0/python
--enable-languages=c,c++,java,fortran --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 6.3.0 p1.0' --disable-esp --enable-libstdcxx-time
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64
--disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp
--disable-libmudflap --disable-libssp --disable-libcilkrts --disable-libmpx
--enable-vtable-verify --enable-libvtv --enable-lto --without-isl
--enable-libsanitizer --disable-default-pie --disable-default-ssp
Thread model: posix
gcc version 6.3.0 (Gentoo 6.3.0 p1.0)
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Manuel López-Ibáñez changed: What|Removed |Added CC||TrevorJamesHickey at gmail dot com --- Comment #28 from Manuel López-Ibáñez --- *** Bug 72837 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Manuel López-Ibáñez changed: What|Removed |Added CC||msebor at gcc dot gnu.org --- Comment #27 from Manuel López-Ibáñez --- *** Bug 70888 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
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
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
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).
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
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.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
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.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #22 from Jeffrey Walton noloader at gmail dot com --- (In reply to Jonathan Wakely from comment #18) ... Or you could just change the code causing the warnings. Fair enough. There are two warnings that are big offenders. First is the unused variable warning due to a static assert. I asked for help with it at https://gcc.gnu.org/ml/gcc-help/2015-07/msg00070.html. Second is the unknown pragma warning. Here's part of the problem, but I don't expect much to come of it: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431. Here's another piece of the same problem: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66943. I really don't understand the 66942 warning since GCC is an OpenMP conforming compiler. '#pragma omp' is known to it in all configurations. The only thing that changes is OMP is active when '-fopenmp' is passed on the command line. Jeff
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #21 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #14) (In reply to Jeffrey Walton from comment #13) #if GCC_DIAGNOSTIC_AWARE # pragma GCC diagnostic push # pragma GCC diagnostic ignored -Wunused-value # pragma GCC diagnostic ignored -Wunused-variable #endif As far as I understand, the #pragma should work as expected for those two warnings. Only those warnings given during preprocessing and lexing are affected by this bug. 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.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
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.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 --- Comment #14 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Jeffrey Walton from comment #13) #if GCC_DIAGNOSTIC_AWARE # pragma GCC diagnostic push # pragma GCC diagnostic ignored -Wunused-value # pragma GCC diagnostic ignored -Wunused-variable #endif As far as I understand, the #pragma should work as expected for those two warnings. Only those warnings given during preprocessing and lexing are affected by this bug.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53431 Allan Chandler allan.chandler at oakton dot com.au changed: What|Removed |Added CC||allan.chandler at oakton dot com.a ||u --- Comment #11 from Allan Chandler allan.chandler at oakton dot com.au --- http://stackoverflow.com/questions/31509434/gcc-does-not-honor-pragma-gcc-diagnostic-to-silence-warnings 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 :-)
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
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, bootstrapregression 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.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
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=35688action=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.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
https://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||bero at arklinux dot org --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 48914 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic
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.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored -Wundef
https://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||ruslan_baratov at yahoo dot com --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org --- *** Bug 61653 has been marked as a duplicate of this bug. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored -Wundef
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
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.
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored -Wundef
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. ***
[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic ignored -Wundef
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
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
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
