Say I have the following file: $ cat __extension__.c const char *str0 = "\e"; const char *str1 = __extension__ "\e"; When I try to compile it with gcc, everything works as expected: $ /usr/local/bin/gcc -pedantic -c __extension__.c __extension__.c:1:20: warning: non-ISO-standard escape sequence, '\e' const char *str0 = "\e"; ^~~~ i.e., it only warns on the string where I left off the __extension__. However, when I try to compile it with g++, it warns on both strings: $ /usr/local/bin/g++ -pedantic -c __extension__.c __extension__.c:1:20: warning: non-ISO-standard escape sequence, '\e' const char *str0 = "\e"; ^~~~ __extension__.c:2:34: warning: non-ISO-standard escape sequence, '\e' const char *str1 = __extension__ "\e"; ^~~~ This behavior is inconsistent. I would expect the warning for the string with __extension__ to be silenced in both cases, not just in C. g++ version info: $ /usr/local/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/local/bin/g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i386-apple-darwin9.8.0/7.0.0/lto-wrapper Target: i386-apple-darwin9.8.0 Configured with: ../configure --disable-werror --enable-languages=c,c++,lto,objc,obj-c++ --enable-stage1-checking=release -C --with-system-libunwind --enable-secureplt --enable-frame-pointer --enable-version-specific-runtime-libs --enable-assert --enable-fat --enable-portable-binary --enable-browser-plugin --enable-gconf-peer --enable-libgcj-debug --enable-gc-debug --enable-interpreter --enable-aot-compile-rpm --enable-java-home --with-x --enable-collections --enable-gstreamer-peer --enable-xmlj --enable-qt-peer --enable-debug --enable-local-sockets --without-isl --enable-objc-gc --enable-maintainer-mode --enable-host-shared CC=/usr/local/bin/gcc CXX=/usr/local/bin/g++ AUTOCONF=/usr/local/bin/autoconf AUTOHEADER=/usr/local/bin/autoheader AUTOM4TE=/usr/local/bin/autom4te AUTORECONF=/usr/local/bin/autoreconf AUTOSCAN=/usr/local/bin/autoscan AUTOUPDATE=/usr/local/bin/autoupdate IFNAMES=/usr/local/bin/ifnames Thread model: posix gcc version 7.0.0 20160426 (experimental) (GCC)
Confirmed. The manual says clearly that it should work so this is a G++ bug. '-Wpedantic' does not cause warning messages for use of the alternate keywords whose names begin and end with '__'. Pedantic warnings are also disabled in the expression that follows __extension__.
(In reply to Martin Sebor from comment #1) > Confirmed. The manual says clearly that it should work so this is a G++ bug. > > '-Wpedantic' does not cause warning messages for use of the alternate > keywords > whose names begin and end with '__'. Pedantic warnings are also disabled in > the expression that follows __extension__. Thanks for confirming.
I'm pretty sure that this applies to all pedantic warnings that occur while preprocessing: const int a0 = 0b101010; const int a1 = __extension__ 0b101010; C++ lexes everything at once without parsing __extension__. Same problem with pragma diagnostics (bug 53431). Either these warnings are moved from the preprocessor to the FE, that is, somehow delayed, or the preprocessor has to learn about __extension__ and pragma diagnostics. I'm surprised there is no older report about this.
There's PR 87274 as well.
(In reply to Manuel López-Ibáñez from comment #3) > I'm pretty sure that this applies to all pedantic warnings that occur while > preprocessing: > > const int a0 = 0b101010; > const int a1 = __extension__ 0b101010; > > C++ lexes everything at once without parsing __extension__. > > Same problem with pragma diagnostics (bug 53431). > > Either these warnings are moved from the preprocessor to the FE, that is, > somehow delayed, or the preprocessor has to learn about __extension__ and > pragma diagnostics. I think the second option would make more sense
The issue of __extension__ not working with the preprocessor came up again here: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575414.html