Hi! On 2022-12-15T12:50:44+0100, Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > On Thu, Dec 15, 2022 at 12:39:38PM +0100, Iain Buclaw wrote: >> For the gdc testsuite, those warnings arise because both language files >> are compiled in the same invocation (dg-additional-sources "cpp11.cpp"), >> so it ends up looking something like: >> >> gdc -fextern-std=c++11 testcpp11.d cpp11.cpp -o testcpp11.exe
..., and this is a compilation mode that GCC generally intends to support, right? For example, also in use with Fortran, to bring in C code. >From that it follows that it's either the duty of all drivers ('gcc', 'g++', 'gdc', 'gfortran', 'grust', etc.) to appropriately handle such options (like, "Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option" that I proposed), or indeed: > Maybe it would be nice to be able to pass options only to a certain > gcc backend binary and not to others, similarly to how > -Wa,option passes options to assembler, -Wp,option to preprocessor and > -Wl,option to linker. > -Wc,language,option ? > Then one could > gdc -Wc,d,-fextern-std=c++11 testcpp11.d cpp11.cpp -o testcpp11.exe > or > gccrs -Wc,rust,-frust-incomplete-and-experimental-compiler-do-not-use > whatever.rs something.c -o whatever > etc. > If we do, one would need to use it with care, because then e.g. for > gcc -Wc,c,-fsanitize=address > the driver wouldn't know it should link in -lasan etc. Hmm. :-) On the one hand, I like it (or some similar syntax), on the other hand, isn't this a bit over-engineered? (..., and then also "under-engineered": which front end(s) does "-Wp,option to preprocessor", then apply to, for example; all of them, and we ought to add a mechanism to have separate such options for different front ends...) One step back: Typically, per my understanding, GCC options are intended to convey similar semantics, when they apply to more than one front end. For example, '-Wunused' means similar things in C, C++, Fortran, Rust compilation. 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'. For others, a diagnostic may be considered appropriate. For example, as we already have: cc1: warning: command-line option '-std=c++11' is valid for C++/ObjC++ but not for C But, you could also argue that the 'c++' in '-std=c++11' imples that it's targeted at the 'b.cc' C++ compilation part of 'g++ -std=c++11 a.c b.cc', and 'a.c' is compiled with default C '-std=[...]'; and you might in fact have: 'g++ -std=c89 -std=c++11 a.c b.cc', huh... If we go for extending the syntax, should we do something similar to '-foffload-options', where might have syntax similar to: -ffront-end-options=-ffoo\ -fbar -ffront-end-options=c,c++=-fsigned-char\ -fshort-enums -ffront-end-options=d,rust=[...] That is, in contrast to your proposed '-Wc,[...]', this allows for specifying the same options for multiple front ends in one go. Is that useful? Anyway: how to get us un-stuck here -- maybe pragmatically? :-) 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