Hi! On 2022-12-15T16:17:05+0100, Jakub Jelinek wrote: > On Thu, Dec 15, 2022 at 04:01:33PM +0100, Thomas Schwinge wrote: >> Or, options are applicable to just one front end, and can just be a no-op >> for others, for shared-language compilation. For example, '-nostdinc++', >> or '-frust-incomplete-and-experimental-compiler-do-not-use' need not >> necessarily emit a diagnostic, but can just just be ignored by 'cc1', >> 'f951', 'lto1'. > > One simple change could be to add a new warning option and use it for > complain_wrong_lang warnings: > else if (ok_langs[0] != '\0') > /* Eventually this should become a hard error IMO. */ > warning (0, "command-line option %qs is valid for %s but not for %s", > text, ok_langs, bad_lang); (By the way, that comment was originally added in 2003-06-07 commit 2772ef3ef33609dd64209323e9418a847685971a "Move handling of lang-specific switches to toplev".) > else > /* Happens for -Werror=warning_name. */ > warning (0, "%<-Werror=%> argument %qs is not valid for %s", > text, bad_lang); > We could keep the existing behavior, but give users (and our testsuite) > a way to silence that warning if they are ok with it applying only to a > subset of languages. > Then one could use > -frust-incomplete-and-experimental-compiler-do-not-use -Wno-whatever > or add that -Wno-whatever in check_compile if the snippet is different > language from main language of the testsuite (or always) etc. Like in the attaached "Add '-Wno-complain-wrong-lang', and use it in 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere", for example? Anything that 'gcc/opts-global.cc:complain_wrong_lang' might do is cut short by '-Wno-complain-wrong-lang', not just the one 'warning' diagnostic. This corresponds to what already exists via 'lang_hooks.complain_wrong_lang_p'. The 'gcc/opts-common.cc:prune_options' changes follow the same rationale as PR67640 "driver passes -fdiagnostics-color= always last": we need to process '-Wno-complain-wrong-lang' early, so that it properly affects other options appearing before it on the command line. In the test suites, a number of existing test cases explicitly match the "command-line option [...] is valid for [...] but not for [...]" diagnostic with 'dg-warning'; I've left those alone. On the other hand, I've changed 'dg-prune-output' of this diagnostic into '-Wno-complain-wrong-lang' usage. I'm happy to adjust that in either way anyone may prefer. I've not looked for test cases that just to silence this diagnostic use more general 'dg-prune-output', 'dg-excess-errors', '-w', etc. In the GCC/D test suite, I see a number of: cc1plus: warning: command-line option '-fpreview=in' is valid for D but not for C++ cc1plus: warning: command-line option '-fextern-std=c++11' is valid for D but not for C++ It's not clear to me how they, despite this, do achieve 'PASS: [...] (test for excess errors)'? Maybe I haven't found where that gets pruned/ignored? In addition to the test suites, I'm also seeing: build-gcc/build-x86_64-pc-linux-gnu/libcpp/config.log:cc1: warning: command line option '-fno-rtti' is valid for C++/ObjC++ but not for C [enabled by default] build-gcc/gcc/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/gcc/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/libbacktrace/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/libcc1/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/libcpp/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/lto-plugin/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/libatomic/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/libbacktrace/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/libffi/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/libgfortran/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/libgo/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/libgomp/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/libitm/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/libobjc/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/libphobos/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/libquadmath/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/libsanitizer/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/libssp/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/libstdc++-v3/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/libvtv/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/x86_64-pc-linux-gnu/zlib/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C build-gcc/zlib/config.log:cc1: warning: command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C (Trimmed down.) Maybe there's a point to be made about fixing those (all the same: '-fno-rtti'?), and then "Eventually this should become a hard error IMO" (see above) implemented -- at least for GCC-internal use (for example, via '-Wcomplain-wrong-lang=error', set during GCC bootstrap)? (I still don't have a strong opinion.) Grüße Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955