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

  Hi!

On 2022-12-13T14:40:36+0100, Arthur Cohen <arthur.cohen@embecosm.com> wrote:
> We've also added one more commit, which only affects files inside the
> Rust front-end folder. This commit adds an experimental flag, which
> blocks the compilation of Rust code when not used.

(That's commit r13-4675-gb07ef39ffbf4e77a586605019c64e2e070915ac3
"gccrs: Add fatal_error when experimental flag is not present".)

I noticed that GCC/Rust recently lost all LTO variants in torture
testing -- due to this commit.  :-O

OK to push the attached
"Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option",
or should this be done differently?

With that, we get back:

     PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O0  (test for excess errors)
     PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O1  (test for excess errors)
     PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O2  (test for excess errors)
    +PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
    +PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
     PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O3 -g  (test for excess errors)
     PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -Os  (test for excess errors)

Etc., and in total:

                    === rust Summary for unix ===

    # of expected passes            [-4990-]{+6718+}
    # of expected failures          [-39-]{+51+}


Grüße
 Thomas


> We hope this helps
> indicate to users that the compiler is not yet ready, but can still be
> experimented with :)
>
> We plan on removing that flag as soon as possible, but in the meantime,
> we think it will help not creating divide within the Rust ecosystem, as
> well as not waste Rust crate maintainers' time.


-----------------
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
  

On Wed, Dec 14, 2022 at 11:58 PM Thomas Schwinge
<thomas@codesourcery.com> wrote:
>
> Hi!
>
> On 2022-12-13T14:40:36+0100, Arthur Cohen <arthur.cohen@embecosm.com> wrote:
> > We've also added one more commit, which only affects files inside the
> > Rust front-end folder. This commit adds an experimental flag, which
> > blocks the compilation of Rust code when not used.
>
> (That's commit r13-4675-gb07ef39ffbf4e77a586605019c64e2e070915ac3
> "gccrs: Add fatal_error when experimental flag is not present".)
>
> I noticed that GCC/Rust recently lost all LTO variants in torture
> testing -- due to this commit.  :-O
>
> OK to push the attached
> "Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option",
> or should this be done differently?

Just add 'LTO' to the option in lang.opt, like

frust-incomplete-and-experimental-compiler-do-not-use
Rust LTO Var(flag_rust_experimental)
Enable experimental compilation of Rust files at your own risk


>
> With that, we get back:
>
>      PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O0  (test for excess errors)
>      PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O1  (test for excess errors)
>      PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O2  (test for excess errors)
>     +PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
>     +PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
>      PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O3 -g  (test for excess errors)
>      PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -Os  (test for excess errors)
>
> Etc., and in total:
>
>                     === rust Summary for unix ===
>
>     # of expected passes            [-4990-]{+6718+}
>     # of expected failures          [-39-]{+51+}
>
>
> Grüße
>  Thomas
>
>
> > We hope this helps
> > indicate to users that the compiler is not yet ready, but can still be
> > experimented with :)
> >
> > We plan on removing that flag as soon as possible, but in the meantime,
> > we think it will help not creating divide within the Rust ecosystem, as
> > well as not waste Rust crate maintainers' time.
>
>
> -----------------
> 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
  

Hi!

On 2022-12-15T08:53:13+0100, Richard Biener <richard.guenther@gmail.com> wrote:
> On Wed, Dec 14, 2022 at 11:58 PM Thomas Schwinge
> <thomas@codesourcery.com> wrote:
>> On 2022-12-13T14:40:36+0100, Arthur Cohen <arthur.cohen@embecosm.com> wrote:
>> > We've also added one more commit, which only affects files inside the
>> > Rust front-end folder. This commit adds an experimental flag, which
>> > blocks the compilation of Rust code when not used.
>>
>> (That's commit r13-4675-gb07ef39ffbf4e77a586605019c64e2e070915ac3
>> "gccrs: Add fatal_error when experimental flag is not present".)
>>
>> I noticed that GCC/Rust recently lost all LTO variants in torture
>> testing -- due to this commit.  :-O
>>
>> OK to push the attached
>> "Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option",
>> or should this be done differently?
>
> Just add 'LTO' to the option in lang.opt, like
>
> frust-incomplete-and-experimental-compiler-do-not-use
> Rust LTO Var(flag_rust_experimental)
> Enable experimental compilation of Rust files at your own risk

That doesn't work; it's 'cc1' that is complaining here.


Grüße
 Thomas


>> With that, we get back:
>>
>>      PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O0  (test for excess errors)
>>      PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O1  (test for excess errors)
>>      PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O2  (test for excess errors)
>>     +PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O2 -flto -fno-use-linker-plugin -flto-partition=none  (test for excess errors)
>>     +PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects  (test for excess errors)
>>      PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -O3 -g  (test for excess errors)
>>      PASS: rust/compile/torture/all_doc_comment_line_blocks.rs   -Os  (test for excess errors)
>>
>> Etc., and in total:
>>
>>                     === rust Summary for unix ===
>>
>>     # of expected passes            [-4990-]{+6718+}
>>     # of expected failures          [-39-]{+51+}
>>
>>
>> Grüße
>>  Thomas
>>
>>
>> > We hope this helps
>> > indicate to users that the compiler is not yet ready, but can still be
>> > experimented with :)
>> >
>> > We plan on removing that flag as soon as possible, but in the meantime,
>> > we think it will help not creating divide within the Rust ecosystem, as
>> > well as not waste Rust crate maintainers' time.


-----------------
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
  

On Thu, Dec 15, 2022 at 11:14:10AM +0100, Thomas Schwinge wrote:
> Hi!
> 
> On 2022-12-15T08:53:13+0100, Richard Biener <richard.guenther@gmail.com> wrote:
> > On Wed, Dec 14, 2022 at 11:58 PM Thomas Schwinge
> > <thomas@codesourcery.com> wrote:
> >> On 2022-12-13T14:40:36+0100, Arthur Cohen <arthur.cohen@embecosm.com> wrote:
> >> > We've also added one more commit, which only affects files inside the
> >> > Rust front-end folder. This commit adds an experimental flag, which
> >> > blocks the compilation of Rust code when not used.
> >>
> >> (That's commit r13-4675-gb07ef39ffbf4e77a586605019c64e2e070915ac3
> >> "gccrs: Add fatal_error when experimental flag is not present".)
> >>
> >> I noticed that GCC/Rust recently lost all LTO variants in torture
> >> testing -- due to this commit.  :-O
> >>
> >> OK to push the attached
> >> "Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option",
> >> or should this be done differently?
> >
> > Just add 'LTO' to the option in lang.opt, like
> >
> > frust-incomplete-and-experimental-compiler-do-not-use
> > Rust LTO Var(flag_rust_experimental)
> > Enable experimental compilation of Rust files at your own risk
> 
> That doesn't work; it's 'cc1' that is complaining here.

In that case it is a testsuite issue.
I really think making such Rust option a common option is very much
undesirable.

We seem to have a problem in other testsuites too:
grep ' valid for .*but not for' */*.log | sort -u
gcc/gcc.log:/home/jakub/src/gcc/gcc/testsuite/gcc.dg/pragma-diag-6.c:2:30: warning: option '-Wnoexcept' is valid for C++/ObjC++ but not for C [-Wpragmas]
gdc/gdc.log:cc1plus: warning: command-line option '-fextern-std=c++11' is valid for D but not for C++
gdc/gdc.log:cc1plus: warning: command-line option '-fpreview=in' is valid for D but not for C++
gfortran/gfortran.log:cc1: warning: command-line option '-fcheck=all' is valid for Fortran but not for C
g++/g++.log:cc1: warning: command-line option '-nostdinc++' is valid for C++/ObjC++ but not for C
g++/g++.log:cc1: warning: command-line option '-std=gnu++11' is valid for C++/ObjC++ but not for C
g++/g++.log:cc1: warning: command-line option '-std=gnu++14' is valid for C++/ObjC++ but not for C
g++/g++.log:cc1: warning: command-line option '-std=gnu++17' is valid for C++/ObjC++ but not for C
g++/g++.log:cc1: warning: command-line option '-std=gnu++20' is valid for C++/ObjC++ but not for C
g++/g++.log:cc1: warning: command-line option '-std=gnu++23' is valid for C++/ObjC++ but not for C
g++/g++.log:cc1: warning: command-line option '-std=gnu++98' is valid for C++/ObjC++ but not for C
rust/rust.log:cc1plus: warning: command-line option '-frust-incomplete-and-experimental-compiler-do-not-use' is valid for Rust but not for C++
rust/rust.log:cc1: warning: command-line option '-frust-incomplete-and-experimental-compiler-do-not-use' is valid for Rust but not for C
(of course, some of them could be from tests that this valid for but not for
messages work right, that is clearly the case of pragma-diag-6.c).

In gcc/testsuite/lib/target-supports.exp (check_compile) we already
determine extension for the check_compile snippet based on magic comments
with default to .c (Rust nor Modula 2 don't have any, should that be
changed?), shouldn't we at that point based on the language filter out
known options that will not work?

So, given the above, at least when in gdc testsuite and language is
not D filter out -fextern-std=* and -fpreview=in, for gfortran testsuite
and language not Fortran filter out -fcheck=all, when in g++ testsuite and
language is not C++ filter out -nostdinc++, -std=gnu++* and when
in rust testsuite and language is not Rust filter out
-frust-incomplete-and-experimental-compiler-do-not-use ?

	Jakub
  

Excerpts from Jakub Jelinek via Gcc-patches's message of Dezember 15, 2022 12:16 pm:
> We seem to have a problem in other testsuites too:
> grep ' valid for .*but not for' */*.log | sort -u
> gcc/gcc.log:/home/jakub/src/gcc/gcc/testsuite/gcc.dg/pragma-diag-6.c:2:30: warning: option '-Wnoexcept' is valid for C++/ObjC++ but not for C [-Wpragmas]
> gdc/gdc.log:cc1plus: warning: command-line option '-fextern-std=c++11' is valid for D but not for C++
> gdc/gdc.log:cc1plus: warning: command-line option '-fpreview=in' is valid for D but not for C++
> gfortran/gfortran.log:cc1: warning: command-line option '-fcheck=all' is valid for Fortran but not for C
> g++/g++.log:cc1: warning: command-line option '-nostdinc++' is valid for C++/ObjC++ but not for C
> g++/g++.log:cc1: warning: command-line option '-std=gnu++11' is valid for C++/ObjC++ but not for C
> g++/g++.log:cc1: warning: command-line option '-std=gnu++14' is valid for C++/ObjC++ but not for C
> g++/g++.log:cc1: warning: command-line option '-std=gnu++17' is valid for C++/ObjC++ but not for C
> g++/g++.log:cc1: warning: command-line option '-std=gnu++20' is valid for C++/ObjC++ but not for C
> g++/g++.log:cc1: warning: command-line option '-std=gnu++23' is valid for C++/ObjC++ but not for C
> g++/g++.log:cc1: warning: command-line option '-std=gnu++98' is valid for C++/ObjC++ but not for C
> rust/rust.log:cc1plus: warning: command-line option '-frust-incomplete-and-experimental-compiler-do-not-use' is valid for Rust but not for C++
> rust/rust.log:cc1: warning: command-line option '-frust-incomplete-and-experimental-compiler-do-not-use' is valid for Rust but not for C
> (of course, some of them could be from tests that this valid for but not for
> messages work right, that is clearly the case of pragma-diag-6.c).
> 
> In gcc/testsuite/lib/target-supports.exp (check_compile) we already
> determine extension for the check_compile snippet based on magic comments
> with default to .c (Rust nor Modula 2 don't have any, should that be
> changed?), shouldn't we at that point based on the language filter out
> known options that will not work?
> 
> So, given the above, at least when in gdc testsuite and language is
> not D filter out -fextern-std=* and -fpreview=in, for gfortran testsuite
> and language not Fortran filter out -fcheck=all, when in g++ testsuite and
> language is not C++ filter out -nostdinc++, -std=gnu++* and when
> in rust testsuite and language is not Rust filter out
> -frust-incomplete-and-experimental-compiler-do-not-use ?
> 

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

So ruling out some sort of filtering done by the gdc driver when
delegating calls to the C/C++/D language compilers, is there a way to
get dejagnu to compile dg-additional-sources one-at-a-time?

Iain.
  

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
> 
> So ruling out some sort of filtering done by the gdc driver when
> delegating calls to the C/C++/D language compilers, is there a way to
> get dejagnu to compile dg-additional-sources one-at-a-time?

Through extra code in *.exp file certainly, invoke
  gdc -c cpp11.cpp -o cpp11.o
and
  gdc -fextern-std=c++11 testcpp11.d cpp11.o -o testcpp11.exe
afterwards, but for dg-additional-sources I don't think so.

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.

	Jakub
  

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
  

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);
  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.

	Jakub