Re: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)

[Thomas Schwinge <thomas@codesourcery.com>]

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