Message ID | 87pmcla8yz.fsf@euler.schwinge.homeip.net |
---|---|
State | New |
Headers | show |
Series | Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4) | expand |
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
From 3b2a8a4df1637a0cad738165a2afa9b34e286fcf Mon Sep 17 00:00:00 2001 From: Thomas Schwinge <thomas@codesourcery.com> Date: Wed, 14 Dec 2022 17:16:42 +0100 Subject: [PATCH] Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option I noticed that GCC/Rust recently lost all LTO variants in torture testing: 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. The reason is that when probing for availability of LTO, we run into: spawn [...]/build-gcc/gcc/testsuite/rust/../../gccrs -B[...]/build-gcc/gcc/testsuite/rust/../../ -fdiagnostics-plain-output -frust-incomplete-and-experimental-compiler-do-not-use -flto -c -o lto8274.o lto8274.c cc1: warning: command-line option '-frust-incomplete-and-experimental-compiler-do-not-use' is valid for Rust but not for C For GCC/Rust testing, this flag is defaulted in 'gcc/testsuite/lib/rust.exp:rust_init': lappend ALWAYS_RUSTFLAGS "additional_flags=-frust-incomplete-and-experimental-compiler-do-not-use" Make it generally accepted without "is valid for Rust but not for [...]" diagnostic. gcc/rust/ * lang.opt (-frust-incomplete-and-experimental-compiler-do-not-use): Remove. gcc/ * common.opt (-frust-incomplete-and-experimental-compiler-do-not-use): New. --- gcc/common.opt | 6 ++++++ gcc/rust/lang.opt | 4 ---- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/gcc/common.opt b/gcc/common.opt index 562d73d7f552..eba28e650f94 100644 --- a/gcc/common.opt +++ b/gcc/common.opt @@ -2552,6 +2552,12 @@ frounding-math Common Var(flag_rounding_math) Optimization SetByCombined Disable optimizations that assume default FP rounding behavior. +; This option applies to Rust only, but is defined 'Common' here, so that it's +; generally accepted without "is valid for Rust but not for [...]" diagnostic. +frust-incomplete-and-experimental-compiler-do-not-use +Common Var(flag_rust_experimental) +Enable experimental compilation of Rust files at your own risk. + fsched-interblock Common Var(flag_schedule_interblock) Init(1) Optimization Enable scheduling across basic blocks. diff --git a/gcc/rust/lang.opt b/gcc/rust/lang.opt index 63732a636a3d..6187fbf29352 100644 --- a/gcc/rust/lang.opt +++ b/gcc/rust/lang.opt @@ -66,10 +66,6 @@ frust-dump- Rust Joined RejectNegative -frust-dump-<type> Dump Rust frontend internal information. -frust-incomplete-and-experimental-compiler-do-not-use -Rust Var(flag_rust_experimental) -Enable experimental compilation of Rust files at your own risk - frust-max-recursion-depth= Rust RejectNegative Type(int) Var(rust_max_recursion_depth) Init(64) -frust-max-recursion-depth=integer -- 2.35.1