Hi!
On 2022-12-15T12:50:44+0100, Jakub Jelinek via Gcc-patches
<gcc-patc...@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
--
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust
