Add '-Wno-complain-wrong-lang', and use it in 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere (was: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option)

2022-12-16 Thread Thomas Schwinge 
Hi!

On 2022-12-15T16:17:05+0100, Jakub Jelinek  wrote:
> 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);

(By the way, that comment was originally added in 2003-06-07
commit 2772ef3ef33609dd64209323e9418a847685971a
"Move handling of lang-specific switches to toplev".)

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

Like in the attaached
"Add '-Wno-complain-wrong-lang', and use it in 
'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere",
for example?

Anything that 'gcc/opts-global.cc:complain_wrong_lang' might do is cut
short by '-Wno-complain-wrong-lang', not just the one 'warning'
diagnostic.  This corresponds to what already exists via
'lang_hooks.complain_wrong_lang_p'.

The 'gcc/opts-common.cc:prune_options' changes follow the same rationale
as PR67640 "driver passes -fdiagnostics-color= always last": we need to
process '-Wno-complain-wrong-lang' early, so that it properly affects
other options appearing before it on the command line.


In the test suites, a number of existing test cases explicitly match the
"command-line option [...] is valid for [...] but not for [...]"
diagnostic with 'dg-warning'; I've left those alone.  On the other hand,
I've changed 'dg-prune-output' of this diagnostic into
'-Wno-complain-wrong-lang' usage.  I'm happy to adjust that in either way
anyone may prefer.  I've not looked for test cases that just to silence
this diagnostic use more general 'dg-prune-output', 'dg-excess-errors',
'-w', etc.

In the GCC/D test suite, I see a number of:

cc1plus: warning: command-line option '-fpreview=in' is valid for D but not 
for C++

cc1plus: warning: command-line option '-fextern-std=c++11' is valid for D 
but not for C++

It's not clear to me how they, despite this, do achieve
'PASS: [...] (test for excess errors)'?  Maybe I haven't found where that
gets pruned/ignored?


In addition to the test suites, I'm also seeing:

build-gcc/build-x86_64-pc-linux-gnu/libcpp/config.log:cc1: warning: command 
line option '-fno-rtti' is valid for C++/ObjC++ but not for C [enabled by 
default]
build-gcc/gcc/config.log:cc1: warning: command-line option '-fno-rtti' is 
valid for C++/D/ObjC++ but not for C
build-gcc/gcc/config.log:cc1: warning: command-line option '-fno-rtti' is 
valid for C++/D/ObjC++ but not for C
build-gcc/libbacktrace/config.log:cc1: warning: command-line option 
'-fno-rtti' is valid for C++/D/ObjC++ but not for C
build-gcc/libcc1/config.log:cc1: warning: command-line option '-fno-rtti' 
is valid for C++/D/ObjC++ but not for C
build-gcc/libcpp/config.log:cc1: warning: command-line option '-fno-rtti' 
is valid for C++/D/ObjC++ but not for C
build-gcc/lto-plugin/config.log:cc1: warning: command-line option 
'-fno-rtti' is valid for C++/D/ObjC++ but not for C
build-gcc/x86_64-pc-linux-gnu/libatomic/config.log:cc1: warning: 
command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C
build-gcc/x86_64-pc-linux-gnu/libbacktrace/config.log:cc1: warning: 
command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C
build-gcc/x86_64-pc-linux-gnu/libffi/config.log:cc1: warning: command-line 
option '-fno-rtti' is valid for C++/D/ObjC++ but not for C
build-gcc/x86_64-pc-linux-gnu/libgfortran/config.log:cc1: warning: 
command-line option '-fno-rtti' is valid for C++/D/ObjC++ but not for C
build-gcc/x86_64-pc-linux-gnu/libgo/config.log:cc1: warning: command-line 
option '-fno-rtti' is valid for C++/D/ObjC++ but not for C
build-gcc/x86_64-pc-linux-gnu/libgomp/config.log:cc1: warning: command-line 
option '-fno-rtti' is valid for C++/D/ObjC++ but not for C
build-gcc/x86_64-pc-linux-gnu/libitm/config.log:cc1: warning: command-line 
option '-fno-rtti' is valid for C++/D/ObjC++ but not for C
build-gcc/x86_64-pc-linux-gnu/libobjc/config.log:cc1: warni

[Bug rust/108113] Rust and --enable-link-serialization=1

2022-12-16 Thread tschwinge at gcc dot gnu.org via Gcc-rust 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #2 from Thomas Schwinge  ---
Marc, given Jakub's approval in
, are you
going to push "rust: fix link serialization [PR108113]" to GCC upstream master
branch, too?

---

There's no reason, in opinion, to block such ongoing development/fixes on the
GCC/Rust backlog upstreaming process.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust

Re: Add '-Wno-complain-wrong-lang', and use it in 'gcc/testsuite/lib/target-supports.exp:check_compile' and elsewhere (was: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' opt

2022-12-16 Thread Iain Buclaw via Gcc-rust 
Excerpts from Thomas Schwinge's message of Dezember 16, 2022 3:10 pm:
> 
> In the test suites, a number of existing test cases explicitly match the
> "command-line option [...] is valid for [...] but not for [...]"
> diagnostic with 'dg-warning'; I've left those alone.  On the other hand,
> I've changed 'dg-prune-output' of this diagnostic into
> '-Wno-complain-wrong-lang' usage.  I'm happy to adjust that in either way
> anyone may prefer.  I've not looked for test cases that just to silence
> this diagnostic use more general 'dg-prune-output', 'dg-excess-errors',
> '-w', etc.
> 
> In the GCC/D test suite, I see a number of:
> 
> cc1plus: warning: command-line option '-fpreview=in' is valid for D but 
> not for C++
> 
> cc1plus: warning: command-line option '-fextern-std=c++11' is valid for D 
> but not for C++
> 
> It's not clear to me how they, despite this, do achieve
> 'PASS: [...] (test for excess errors)'?  Maybe I haven't found where that
> gets pruned/ignored?
> 

There's an implicit dg-prune-output inserted by the gdc-convert-test
proc. As the only tests that mix C++ and D sources is the runnable_cxx
part of the testsuite, I can add the flag to the D2 testsuite scripts
later just for those tests.

Iain.
-- 
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust