[Bug rust/108124] New: UBSAN issues when tests are run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108124 Bug ID: 108124 Summary: UBSAN issues when tests are run Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rust Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org Target Milestone: --- I built GCC compiler with ASAN & UBSAN enabled: F="-fsanitize=address,undefined -g -O2" ; make -j32 all-host -k CFLAGS="$F" CXXFLAGS="$F" LDFLAGS="$F" and I see a couple of issues: ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/rust/compile/torture/must_use2.rs -c /usr/include/c++/12/bits/stl_iterator.h:1096:17: runtime error: reference binding to null pointer of type 'struct SubstitutionParamMapping' #0 0x3be00ae in __gnu_cxx::__normal_iterator > >::operator*() const /usr/include/c++/12/bits/stl_iterator.h:1096 #1 0x3be00ae in std::vector >::front() /usr/include/c++/12/bits/stl_vector.h:1207 #2 0x3be00ae in Rust::TyTy::TypeBoundPredicate::TypeBoundPredicate(Rust::DefId, std::vector >, Location) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-bounds.cc:129 #3 0x3be0ea3 in Rust::TyTy::TypeBoundPredicate::error() /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-bounds.cc:207 #4 0x3cc9cb8 in Rust::Resolver::TypeCheckItem::visit(Rust::HIR::ImplBlock&) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-item.cc:74 #5 0x3cc72e7 in Rust::Resolver::TypeCheckItem::Resolve(Rust::HIR::Item&) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-item.cc:39 #6 0x39c3724 in Rust::Resolver::TypeResolution::Resolve(Rust::HIR::Crate&) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check.cc:48 #7 0x2aff5ff in Rust::Session::compile_crate(char const*) /home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:565 #8 0x2b0420e in Rust::Session::handle_input_files(int, char const**) /home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:362 #9 0x212ce46 in grs_langhook_parse_file /home/marxin/Programming/gcc/gcc/rust/rust-lang.cc:184 #10 0xcf3b22e in compile_file /home/marxin/Programming/gcc/gcc/toplev.cc:444 #11 0xcf4f14d in do_compile /home/marxin/Programming/gcc/gcc/toplev.cc:2125 #12 0xcf4f14d in toplev::main(int, char**) /home/marxin/Programming/gcc/gcc/toplev.cc:2277 #13 0x10409e86 in main /home/marxin/Programming/gcc/gcc/main.cc:39 #14 0x76a2c5af in __libc_start_call_main (/lib64/libc.so.6+0x275af) #15 0x76a2c678 in __libc_start_main_impl (/lib64/libc.so.6+0x27678) #16 0x212cbd4 in _start ../sysdeps/x86_64/start.S:115 /usr/include/c++/12/bits/stl_vector.h:1207:16: runtime error: reference binding to null pointer of type 'struct value_type' #0 0x3be00e8 in std::vector >::front() /usr/include/c++/12/bits/stl_vector.h:1207 #1 0x3be00e8 in Rust::TyTy::TypeBoundPredicate::TypeBoundPredicate(Rust::DefId, std::vector >, Location) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-bounds.cc:129 #2 0x3be0ea3 in Rust::TyTy::TypeBoundPredicate::error() /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-bounds.cc:207 #3 0x3cc9cb8 in Rust::Resolver::TypeCheckItem::visit(Rust::HIR::ImplBlock&) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-item.cc:74 #4 0x3cc72e7 in Rust::Resolver::TypeCheckItem::Resolve(Rust::HIR::Item&) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-item.cc:39 #5 0x39c3724 in Rust::Resolver::TypeResolution::Resolve(Rust::HIR::Crate&) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check.cc:48 #6 0x2aff5ff in Rust::Session::compile_crate(char const*) /home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:565 #7 0x2b0420e in Rust::Session::handle_input_files(int, char const**) /home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:362 #8 0x212ce46 in grs_langhook_parse_file /home/marxin/Programming/gcc/gcc/rust/rust-lang.cc:184 #9 0xcf3b22e in compile_file /home/marxin/Programming/gcc/gcc/toplev.cc:444 #10 0xcf4f14d in do_compile /home/marxin/Programming/gcc/gcc/toplev.cc:2125 #11 0xcf4f14d in toplev::main(int, char**) /home/marxin/Programming/gcc/gcc/toplev.cc:2277 #12 0x10409e86 in main /home/marxin/Programming/gcc/gcc/main.cc:39 #13 0x76a2c5af in __libc_start_call_main (/lib64/libc.so.6+0x275af) #14 0x76a2c678 in __libc_start_main_impl (/lib64/libc.so.6+0x27678) #15 0x212cbd4 in _start ../sysdeps/x86_64/start.S:115 /home/marxin/Programming/gcc/gcc/rust/util/fnv-hash.h:73:15: runtime error: shift exponent 6685089673273576526 is too large for 64-bit type 'long unsigned int' #0 0x2b84979 in Rust::Hash::FNV128::write(unsigned char const*, unsigned long) /home/marxin/Programming/gcc/gcc/rust/util/fnv-hash.h:73 #1 0x2b84979 in l
[Bug rust/108124] Rust: UBSAN issues when tests are run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108124 Martin Liška changed: What|Removed |Added Target Milestone|--- |13.0 Last reconfirmed||2022-12-15 Ever confirmed|0 |1 Summary|UBSAN issues when tests are |Rust: UBSAN issues when |run |tests are run CC||cohenarthur at gcc dot gnu.org Status|UNCONFIRMED |NEW -- 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
[Bug rust/108124] Rust: UBSAN issues when tests are run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108124 --- Comment #1 from Martin Liška --- ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/rust/compile/macro19.rs -w /home/marxin/Programming/gcc/gcc/rust/ast/rust-stmt.h:342:48: runtime error: load of value 190, which is not a valid value for type 'bool' #0 0x3546c7e in Rust::AST::ExprStmtWithBlock::is_semicolon_followed() const /home/marxin/Programming/gcc/gcc/rust/ast/rust-stmt.h:342 #1 0x3546c7e in Rust::HIR::ASTLoweringStmt::visit(Rust::AST::ExprStmtWithBlock&) /home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower-stmt.h:78 #2 0x35510cd in Rust::HIR::ASTLoweringStmt::translate(Rust::AST::Stmt*, bool*) /home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower-stmt.h:42 #3 0x3521208 in Rust::HIR::ASTLoweringBlock::visit(Rust::AST::BlockExpr&) /home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower.cc:113 #4 0x354de9e in Rust::HIR::ASTLoweringBlock::translate(Rust::AST::BlockExpr*, bool*) /home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower-block.h:36 #5 0x36ef7fa in Rust::HIR::ASTLoweringItem::visit(Rust::AST::Function&) /home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower-item.cc:428 #6 0x36b8646 in Rust::HIR::ASTLoweringItem::translate(Rust::AST::Item*) /home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower-item.cc:28 #7 0x351caeb in Rust::HIR::ASTLowering::go() /home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower.cc:75 #8 0x351f7d9 in Rust::HIR::ASTLowering::Resolve(Rust::AST::Crate&) /home/marxin/Programming/gcc/gcc/rust/hir/rust-ast-lower.cc:65 #9 0x2afebf5 in Rust::Session::compile_crate(char const*) /home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:549 #10 0x2b0420e in Rust::Session::handle_input_files(int, char const**) /home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:362 #11 0x212ce46 in grs_langhook_parse_file /home/marxin/Programming/gcc/gcc/rust/rust-lang.cc:184 #12 0xcf3b22e in compile_file /home/marxin/Programming/gcc/gcc/toplev.cc:444 #13 0xcf4f14d in do_compile /home/marxin/Programming/gcc/gcc/toplev.cc:2125 #14 0xcf4f14d in toplev::main(int, char**) /home/marxin/Programming/gcc/gcc/toplev.cc:2277 #15 0x10409e86 in main /home/marxin/Programming/gcc/gcc/main.cc:39 #16 0x76a2c5af in __libc_start_call_main (/lib64/libc.so.6+0x275af) #17 0x76a2c678 in __libc_start_main_impl (/lib64/libc.so.6+0x27678) #18 0x212cbd4 in _start ../sysdeps/x86_64/start.S:115 -- 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
[Bug rust/108124] Rust: ASAN&UBSAN issues when tests are run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108124 Martin Liška changed: What|Removed |Added Summary|Rust: UBSAN issues when |Rust: ASAN&UBSAN issues |tests are run |when tests are run --- Comment #2 from Martin Liška --- One more example of ASAN issue: /dev/shm/objdir2/gcc/testsuite/rust10/../../gccrs -B/dev/shm/objdir2/gcc/testsuite/rust10/../../ /home/marxin/Programming/gcc/gcc/testsuite/rust/compile/torture/generics16.rs -fdiagnostics-plain-output -frust-incomplete-and-experimental-compiler-do-not-use -O0 -S -o generics16.s /usr/include/c++/12/bits/stl_iterator.h:1096:17: runtime error: reference binding to null pointer of type 'struct SubstitutionParamMapping' /usr/include/c++/12/bits/stl_vector.h:1207:16: runtime error: reference binding to null pointer of type 'struct value_type' = ==13693==ERROR: AddressSanitizer: heap-use-after-free on address 0x60e05700 at pc 0x03b57bfe bp 0x7fff9a10 sp 0x7fff9a08 READ of size 4 at 0x60e05700 thread T0 #0 0x3b57bfd in Rust::TyTy::BaseType::get_kind() const /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty.h:206 #1 0x3b57bfd in Rust::TyTy::BaseRules::unify(Rust::TyTy::BaseType*) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-rules.h:113 #2 0x3a87ea1 in Rust::TyTy::IntType::unify(Rust::TyTy::BaseType*) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty.cc:1880 #3 0x3b77be0 in Rust::TyTy::ADTRules::visit(Rust::TyTy::ADTType&) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-rules.h:1125 #4 0x3b54d25 in Rust::TyTy::BaseRules::unify(Rust::TyTy::BaseType*) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-rules.h:81 #5 0x3a87121 in Rust::TyTy::ADTType::unify(Rust::TyTy::BaseType*) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty.cc:980 #6 0x3ece21f in Rust::Resolver::TypeCheckImplItem::visit(Rust::HIR::Function&) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-implitem.cc:369 #7 0x3ed2071 in Rust::Resolver::TypeCheckImplItem::Resolve(Rust::HIR::ImplBlock*, Rust::HIR::ImplItem*, Rust::TyTy::BaseType*) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-implitem.cc:338 #8 0x3ccdd4b in Rust::Resolver::TypeCheckItem::visit(Rust::HIR::ImplBlock&) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-item.cc:118 #9 0x3cc72e7 in Rust::Resolver::TypeCheckItem::Resolve(Rust::HIR::Item&) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check-item.cc:39 #10 0x39c3724 in Rust::Resolver::TypeResolution::Resolve(Rust::HIR::Crate&) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-hir-type-check.cc:48 #11 0x2aff5ff in Rust::Session::compile_crate(char const*) /home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:565 #12 0x2b0420e in Rust::Session::handle_input_files(int, char const**) /home/marxin/Programming/gcc/gcc/rust/rust-session-manager.cc:362 #13 0x212ce46 in grs_langhook_parse_file /home/marxin/Programming/gcc/gcc/rust/rust-lang.cc:184 #14 0xcf3b22e in compile_file /home/marxin/Programming/gcc/gcc/toplev.cc:444 #15 0xcf4f14d in do_compile /home/marxin/Programming/gcc/gcc/toplev.cc:2125 #16 0xcf4f14d in toplev::main(int, char**) /home/marxin/Programming/gcc/gcc/toplev.cc:2277 #17 0x10409e86 in main /home/marxin/Programming/gcc/gcc/main.cc:39 #18 0x76a2c5af in __libc_start_call_main (/lib64/libc.so.6+0x275af) #19 0x76a2c678 in __libc_start_main_impl (/lib64/libc.so.6+0x27678) #20 0x212cbd4 in _start ../sysdeps/x86_64/start.S:115 0x60e05700 is located 32 bytes inside of 152-byte region [0x60e056e0,0x60e05778) freed by thread T0 here: #0 0x778bb0e8 (/lib64/libasan.so.8+0xbb0e8) #1 0x3b8f222 in Rust::TyTy::TypeCheckCallExpr::visit(Rust::TyTy::ADTType&) /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty-call.cc:69 previously allocated by thread T0 here: #0 0x778bc40f in __interceptor_malloc (/lib64/libasan.so.8+0xbc40f) #1 0x109248eb in operator new(unsigned long) ../../../../libstdc++-v3/libsupc++/new_op.cc:50 SUMMARY: AddressSanitizer: heap-use-after-free /home/marxin/Programming/gcc/gcc/rust/typecheck/rust-tyty.h:206 in Rust::TyTy::BaseType::get_kind() const Shadow bytes around the buggy address: 0x0c1c7fff8a90: 00 00 00 00 00 00 00 00 00 00 00 00 fa fa fa fa 0x0c1c7fff8aa0: fa fa fa fa 00 00 00 00 00 00 00 00 00 00 00 00 0x0c1c7fff8ab0: 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa fa 0x0c1c7fff8ac0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c1c7fff8ad0: 00 00 00 fa fa fa fa fa fa fa fa fa fd fd fd fd =>0x0c1c7fff8ae0:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fa 0x0c1c7fff8af0: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00 0x0c1c7fff8b00: 00 0
Re: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)
Hi!
On 2022-12-15T08:53:13+0100, Richard Biener wrote:
> On Wed, Dec 14, 2022 at 11:58 PM Thomas Schwinge
> wrote:
>> On 2022-12-13T14:40:36+0100, Arthur Cohen 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
>From 3b2a8a4df1637a0cad738165a2afa9b34e286fcf Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
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_mat
[Bug rust/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 Martin Liška changed: What|Removed |Added Last reconfirmed||2022-12-15 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 CC||marxin at gcc dot gnu.org -- 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
[Bug rust/108111] Rust meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Last reconfirmed||2022-12-15 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW -- 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: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)
On Thu, Dec 15, 2022 at 11:14:10AM +0100, Thomas Schwinge wrote: > Hi! > > On 2022-12-15T08:53:13+0100, Richard Biener > wrote: > > On Wed, Dec 14, 2022 at 11:58 PM Thomas Schwinge > > wrote: > >> On 2022-12-13T14:40:36+0100, Arthur Cohen > >> 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 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug rust/108126] New: rust meets cppcheck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108126 Bug ID: 108126 Summary: rust meets cppcheck Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rust Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org Target Milestone: --- I just ran the C/C++ static analyser over the new source code of rust. First the errors: trunk.d1/gcc/rust/ast/rust-cond-compilation.h:228:65: error: Member variable 'cfg_attrs' is initialized by itself. [selfInitialization] trunk.d1/gcc/rust/typecheck/rust-tyty.h:1635:46: error: Reference to local variable returned. [returnReference] trunk.d1/gcc/rust/typecheck/rust-tyty.h:1636:58: error: Reference to local variable returned. [returnReference] trunk.d1/gcc/rust/typecheck/rust-tyty.h:558:58: error: Reference to local variable returned. [returnReference] trunk.d1/gcc/rust/util/rust-optional.h:157:12: error: Reference to local variable returned. [returnReference] Next, the warnings: trunk.d1/gcc/rust/parse/rust-parse-impl.h:12423:21: warning: Access of moved variable 'outer_attrs'. [accessMoved] trunk.d1/gcc/rust/typecheck/rust-tyty-rules.h:394:7: warning: Class 'BaseRules' does not have a copy constructor which is recommended since it has dynamic memory/resource allocation(s). [noCopyConstructor] trunk.d1/gcc/rust/typecheck/rust-tyty-rules.h:394:7: warning: Class 'BaseRules' does not have a operator= which is recommended since it has dynamic memory/resource allocation(s). [noOperatorEq] trunk.d1/gcc/rust/typecheck/rust-substitution-mapper.h:146:7: warning: Class 'SubstMapper' does not have a copy constructor which is recommended since it has dynamic memory/resource allocation(s). [noCopyConstructor] trunk.d1/gcc/rust/typecheck/rust-substitution-mapper.h:146:7: warning: Class 'SubstMapper' does not have a operator= which is recommended since it has dynamic memory/resource allocation(s). [noOperatorEq] trunk.d1/gcc/rust/typecheck/rust-substitution-mapper.h:261:7: warning: Class 'SubstMapperInternal' does not have a copy constructor which is recommended since it has dynamic memory/resource allocation(s). [noCopyConstructor] trunk.d1/gcc/rust/typecheck/rust-substitution-mapper.h:261:7: warning: Class 'SubstMapperInternal' does not have a operator= which is recommended since it has dynamic memory/resource allocation(s). [noOperatorEq] trunk.d1/gcc/rust/typecheck/rust-tyty-call.h:75:7: warning: Class 'TypeCheckCallExpr' does not have a copy constructor which is recommended since it has dynamic memory/resource allocation(s). [noCopyConstructor] trunk.d1/gcc/rust/typecheck/rust-tyty-call.h:75:7: warning: Class 'TypeCheckCallExpr' does not have a operator= which is recommended since it has dynamic memory/resource allocation(s). [noOperatorEq] trunk.d1/gcc/rust/typecheck/rust-hir-type-check-struct.cc:29:5: warning: Class 'TypeCheckStructExpr' does not have a copy constructor which is recommended since it has dynamic memory/resource allocation(s). [noCopyConstructor] trunk.d1/gcc/rust/typecheck/rust-hir-type-check-struct.cc:29:5: warning: Class 'TypeCheckStructExpr' does not have a operator= which is recommended since it has dynamic memory/resource allocation(s). [noOperatorEq] trunk.d1/gcc/rust/typecheck/rust-tyty.h:664:9: warning: Either the condition 'argument!=nullptr' is redundant or there is possible null pointer dereference: argument. [nullPointerRedundantCheck] trunk.d1/gcc/rust/typecheck/rust-tyty.h:740:29: warning: Either the condition 'index>mappings.size()' is redundant or 'index' can have the value mappings.size(). Expression 'mappings.at(index)' cause access out of bounds. [containerOutOfBounds] trunk.d1/gcc/rust/expand/rust-macro-substitute-ctx.cc:77:25: warning: Either the condition 'it==fragments.end()' is redundant or there is possible dereference of an invalid iterator: it. [derefInvalidIteratorRedundantCheck] trunk.d1/gcc/rust/backend/rust-tree.cc:155:5: warning: Label 'CASE_CONVERT' is not used. Should this be a 'case' of the enclosing switch()? [unusedLabelSwitch] trunk.d1/gcc/rust/backend/rust-tree.cc:45:5: warning: Label 'CASE_CONVERT' is not used. Should this be a 'case' of the enclosing switch()? [unusedLabelSwitch] trunk.d1/gcc/rust/ast/rust-expr.h:1853:3: warning: Member variable 'CallExpr::fndeclRef' is not initialized in the constructor. [uninitMemberVar] trunk.d1/gcc/rust/ast/rust-expr.h:1862:3: warning: Member variable 'CallExpr::fndeclRef' is not initialized in the copy constructor. [uninitMemberVar] trunk.d1/gcc/rust/util/rust-canonical-path.h:51:18: warning: Member variable 'CanonicalPath::crate_num' is not assigned a value in 'CanonicalPath::operator='. [operatorEqVarError] trunk.d1/gcc/rust/util/rust-canonical-path.h:49:3: warning: Member variable 'CanonicalPath::crate_num' is not initialized in the copy constructor.
Re: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)
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. -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug rust/108126] rust meets cppcheck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108126 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108111 -- 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
[Bug rust/108111] Rust meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108126 -- 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: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)
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 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug rust/108126] rust meets cppcheck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108126 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2022-12-15 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 -- 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
[PATCH] testsuite: Add support for Rust and Modula-2 effective target tests
Hi!
This patch allows magic comments also for Rust and Modula-2
for effective target tests etc. and fixes up the Assembly entry
- it is a glob, so /* Assembly can match /whatever Assembly and
not just /* Assembly.
Tested on x86_64-linux with
make check-g++ RUNTESTFLAGS=i386.exp=pr35513*
and verifying it still uses *.S extension for the property_1_needed
effective target test.
Ok for trunk?
2022-12-15 Jakub Jelinek
* lib/target-supports.exp (check_compile): Add support for
Rust and Modula-2. Use \* rather than * for /* comment for
Assembly.
--- gcc/testsuite/lib/target-supports.exp.jj2022-11-30 10:29:42.217698938
+0100
+++ gcc/testsuite/lib/target-supports.exp 2022-12-15 13:08:47.941221943
+0100
@@ -36,7 +36,9 @@
# "! Fortran" for Fortran code,
# "/* ObjC", for ObjC
# "// ObjC++" for ObjC++
-# and "// Go" for Go
+# "// Go" for Go
+# "// Rust" for Rust
+# and "(* Modula-2" for Modula-2
# If the tool is ObjC/ObjC++ then we overide the extension to .m/.mm to
# allow for ObjC/ObjC++ specific flags.
@@ -58,13 +60,15 @@ proc check_compile {basename type conten
set options ""
}
switch -glob -- $contents {
- "*/* Assembly*" { set src ${basename}[pid].S }
+ "*/\* Assembly*" { set src ${basename}[pid].S }
"*! Fortran*" { set src ${basename}[pid].f90 }
"*// C++*" { set src ${basename}[pid].cc }
"*// D*" { set src ${basename}[pid].d }
"*// ObjC++*" { set src ${basename}[pid].mm }
"*/* ObjC*" { set src ${basename}[pid].m }
"*// Go*" { set src ${basename}[pid].go }
+ "*// Rust*" { set src ${basename}[pid].rs }
+ "*(\* Modula-2*" { set src ${basename}[pid].mod }
default {
switch -- $tool {
"objc" { set src ${basename}[pid].m }
Jakub
--
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: [PATCH] testsuite: Add support for Rust and Modula-2 effective target tests
On Thu, 15 Dec 2022, Jakub Jelinek wrote:
> Hi!
>
> This patch allows magic comments also for Rust and Modula-2
> for effective target tests etc. and fixes up the Assembly entry
> - it is a glob, so /* Assembly can match /whatever Assembly and
> not just /* Assembly.
>
> Tested on x86_64-linux with
> make check-g++ RUNTESTFLAGS=i386.exp=pr35513*
> and verifying it still uses *.S extension for the property_1_needed
> effective target test.
>
> Ok for trunk?
OK.
Thanks,
Richard.
> 2022-12-15 Jakub Jelinek
>
> * lib/target-supports.exp (check_compile): Add support for
> Rust and Modula-2. Use \* rather than * for /* comment for
> Assembly.
>
> --- gcc/testsuite/lib/target-supports.exp.jj 2022-11-30 10:29:42.217698938
> +0100
> +++ gcc/testsuite/lib/target-supports.exp 2022-12-15 13:08:47.941221943
> +0100
> @@ -36,7 +36,9 @@
> # "! Fortran" for Fortran code,
> # "/* ObjC", for ObjC
> # "// ObjC++" for ObjC++
> -# and "// Go" for Go
> +# "// Go" for Go
> +# "// Rust" for Rust
> +# and "(* Modula-2" for Modula-2
> # If the tool is ObjC/ObjC++ then we overide the extension to .m/.mm to
> # allow for ObjC/ObjC++ specific flags.
>
> @@ -58,13 +60,15 @@ proc check_compile {basename type conten
> set options ""
> }
> switch -glob -- $contents {
> - "*/* Assembly*" { set src ${basename}[pid].S }
> + "*/\* Assembly*" { set src ${basename}[pid].S }
> "*! Fortran*" { set src ${basename}[pid].f90 }
> "*// C++*" { set src ${basename}[pid].cc }
> "*// D*" { set src ${basename}[pid].d }
> "*// ObjC++*" { set src ${basename}[pid].mm }
> "*/* ObjC*" { set src ${basename}[pid].m }
> "*// Go*" { set src ${basename}[pid].go }
> + "*// Rust*" { set src ${basename}[pid].rs }
> + "*(\* Modula-2*" { set src ${basename}[pid].mod }
> default {
> switch -- $tool {
> "objc" { set src ${basename}[pid].m }
>
> Jakub
>
>
--
Richard Biener
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)
--
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: [PATCH] testsuite: Add support for Rust and Modula-2 effective target tests
Hi Jakub,
On 12/15/22 13:23, Jakub Jelinek wrote:
Hi!
This patch allows magic comments also for Rust and Modula-2
for effective target tests etc. and fixes up the Assembly entry
- it is a glob, so /* Assembly can match /whatever Assembly and
not just /* Assembly.
Tested on x86_64-linux with
make check-g++ RUNTESTFLAGS=i386.exp=pr35513*
and verifying it still uses *.S extension for the property_1_needed
effective target test.
Ok for trunk?
2022-12-15 Jakub Jelinek
* lib/target-supports.exp (check_compile): Add support for
Rust and Modula-2. Use \* rather than * for /* comment for
Assembly.
--- gcc/testsuite/lib/target-supports.exp.jj2022-11-30 10:29:42.217698938
+0100
+++ gcc/testsuite/lib/target-supports.exp 2022-12-15 13:08:47.941221943
+0100
@@ -36,7 +36,9 @@
# "! Fortran" for Fortran code,
# "/* ObjC", for ObjC
# "// ObjC++" for ObjC++
-# and "// Go" for Go
+# "// Go" for Go
+# "// Rust" for Rust
+# and "(* Modula-2" for Modula-2
# If the tool is ObjC/ObjC++ then we overide the extension to .m/.mm to
# allow for ObjC/ObjC++ specific flags.
@@ -58,13 +60,15 @@ proc check_compile {basename type conten
set options ""
}
switch -glob -- $contents {
- "*/* Assembly*" { set src ${basename}[pid].S }
+ "*/\* Assembly*" { set src ${basename}[pid].S }
"*! Fortran*" { set src ${basename}[pid].f90 }
"*// C++*" { set src ${basename}[pid].cc }
"*// D*" { set src ${basename}[pid].d }
"*// ObjC++*" { set src ${basename}[pid].mm }
"*/* ObjC*" { set src ${basename}[pid].m }
"*// Go*" { set src ${basename}[pid].go }
+ "*// Rust*" { set src ${basename}[pid].rs }
+ "*(\* Modula-2*" { set src ${basename}[pid].mod }
default {
switch -- $tool {
"objc" { set src ${basename}[pid].m }
Jakub
LGTM :)
Thank you,
Arthur
OpenPGP_0x1B3465B044AD9C65.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
--
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: [PATCH] testsuite: Add support for Rust and Modula-2 effective target tests
On Dez 15 2022, Jakub Jelinek via Gcc-rust wrote:
> @@ -58,13 +60,15 @@ proc check_compile {basename type conten
> set options ""
> }
> switch -glob -- $contents {
> - "*/* Assembly*" { set src ${basename}[pid].S }
> + "*/\* Assembly*" { set src ${basename}[pid].S }
That's a no-op. Either double the backslash or quote with {} instead of
"".
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: [PATCH] testsuite: Add support for Rust and Modula-2 effective target tests
On Dez 15 2022, Jakub Jelinek via Gcc-rust wrote:
> @@ -58,13 +60,15 @@ proc check_compile {basename type conten
> set options ""
> }
> switch -glob -- $contents {
> - "*/* Assembly*" { set src ${basename}[pid].S }
> + "*/\* Assembly*" { set src ${basename}[pid].S }
> "*! Fortran*" { set src ${basename}[pid].f90 }
> "*// C++*" { set src ${basename}[pid].cc }
> "*// D*" { set src ${basename}[pid].d }
> "*// ObjC++*" { set src ${basename}[pid].mm }
> "*/* ObjC*" { set src ${basename}[pid].m }
You probably want to quote the * here too.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
--
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust
Re: [PATCH] testsuite: Add support for Rust and Modula-2 effective target tests
On Thu, Dec 15, 2022 at 02:03:36PM +0100, Andreas Schwab wrote:
> On Dez 15 2022, Jakub Jelinek via Gcc-rust wrote:
>
> > @@ -58,13 +60,15 @@ proc check_compile {basename type conten
> > set options ""
> > }
> > switch -glob -- $contents {
> > - "*/* Assembly*" { set src ${basename}[pid].S }
> > + "*/\* Assembly*" { set src ${basename}[pid].S }
> > "*! Fortran*" { set src ${basename}[pid].f90 }
> > "*// C++*" { set src ${basename}[pid].cc }
> > "*// D*" { set src ${basename}[pid].d }
> > "*// ObjC++*" { set src ${basename}[pid].mm }
> > "*/* ObjC*" { set src ${basename}[pid].m }
>
> You probably want to quote the * here too.
You're right on both, I've committed this follow-up
after verifying that Assembly test still works (it works even with \\\*
but doesn't with *) and verifying that changing
check_effective_target_property_1_needed
to have // Assembly instead of /* Assembly incorrectly works with
"*/* Assembly*", "*/\* Assembly*" but correctly doesn't work with
"*/\\* Assembly*" or "*/\\\* Assembly*".
Committed to trunk. Sorry.
2022-12-15 Jakub Jelinek
* lib/target-supports.exp (check_compile): Further quoting
fixes for /* Assembly, /* ObjC and (* Modula-2 *) checks.
--- gcc/testsuite/lib/target-supports.exp.jj2022-12-15 13:57:40.0
+0100
+++ gcc/testsuite/lib/target-supports.exp 2022-12-15 14:14:02.987854385
+0100
@@ -60,15 +60,15 @@ proc check_compile {basename type conten
set options ""
}
switch -glob -- $contents {
- "*/\* Assembly*" { set src ${basename}[pid].S }
+ "*/\\* Assembly*" { set src ${basename}[pid].S }
"*! Fortran*" { set src ${basename}[pid].f90 }
"*// C++*" { set src ${basename}[pid].cc }
"*// D*" { set src ${basename}[pid].d }
"*// ObjC++*" { set src ${basename}[pid].mm }
- "*/* ObjC*" { set src ${basename}[pid].m }
+ "*/\\* ObjC*" { set src ${basename}[pid].m }
"*// Go*" { set src ${basename}[pid].go }
"*// Rust*" { set src ${basename}[pid].rs }
- "*(\* Modula-2*" { set src ${basename}[pid].mod }
+ "*(\\* Modula-2*" { set src ${basename}[pid].mod }
default {
switch -- $tool {
"objc" { set src ${basename}[pid].m }
Jakub
--
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug rust/108126] rust meets cppcheck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108126 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||diagnostic Blocks||89863 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 [Bug 89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses -- 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
☠ Buildbot (GNU Toolchain): gccrust - failed configure (failure) (master)
A new failure has been detected on builder gccrust-fedora-x86_64 while building gccrust. Full details are available at: https://builder.sourceware.org/buildbot/#builders/16/builds/546 Build state: failed configure (failure) Revision: 24ff0b3e0c41e3997fb4c11736b8a412afbaadf3 Worker: bb1-2 Build Reason: (unknown) Blamelist: Aldy Hernandez , Alex Coplan , Alexander Monakov , Alexandre Oliva , Andre Vieira , Andrea Corallo , Andrew Carlotti , Andrew MacLeod , Andrew Pinski , Andrew Pinski , Andrew Stubbs , Antoni Boucher , Arnaud Charlet , Arsen Arsenović , Arthur Cohen , Bernhard Reutner-Fischer , Bernhard Reutner-Fischer , Björn Schäpers , Bob Duff , Boris Yakobowski , Cedric Landet , Cesar Philippidis , Charles-François Natali , Christoph Müllner , Christophe Lyon , Claire Dross , David Faust , David Malcolm , David Seifert , Dimitar Dimitrov , Eric Botcazou , Eric Gallager , Eugene Rozenfeld , Fei Gao , Florian Weimer , François Dumont , Frolov Daniil , GCC Administrator , Gaius Mulley , Gary Dismukes , Ghjuvan Lacambre , H.J. Lu , Hans-Peter Nilsson , Haochen Gui , Haochen Jiang , Harald Anlauf , Hongyu Wang , Hu, Lin1 , Iain Buclaw , Iain Sandoe , Ian Lance Taylor , Iskander Shakirzyanov , Jakob Hasse <0xja...@users.noreply.github.com>, Jakub Jelinek , Jason Merrill , Javier Miranda , Jeff Chapman II , Jeff Law , Jeff Law , Jia-Wei Chen , Jinyang He , Jiufu Guo , Joel Brobecker , Johannes Kliemann , John David Anglin , Jonathan Wakely , Joseph Myers , Josue Nava Bello , José Rui Faustino de Sousa , Ju-Zhe Zhong , Justin Squirek , Kewen Lin , Kewen.Lin , Kwok Cheung Yeung , Kyrylo Tkachov , Lewis Hyatt , Liaiss Merzougue , Lili Cui , Lulu Cheng , Maciej W. Rozycki , Marc Poulhiès , Marcel Vollweiler , Marek Polacek , Martin Jambor , Martin Liska , Max Filippov , Michael Collison , Nathan Sidwell , Nathaniel Shead , Patrick Bernardi , Patrick Palka , Paul Thomas , Paul-Antoine Arras , Philipp Tomsich , Piotr Trojanek , Prathamesh Kulkarni , Qing Zhao , Quentin Ochem , Rainer Orth , Ramana Radhakrishnan , Rasmus Villemoes , Richard Biener , Richard Purdie , Ronan Desplanques , Sam James , Sandra Loosemore , Scott Snyder , Sebastian Huber , Sebastian Pop , Siddhesh Poyarekar , Sinan , Srinath Parvathaneni , Stam Markianos-Wright , Steve Baird , Steve Kargl , Surya Kumari Jangala , Tamar Christina , Thomas Schwinge , Tobias Burnus , Torbjörn SVENSSON , Uros Bizjak , Vladimir N. Makarov , Weimin Pan , Wilco Dijkstra , Wilco Dijkstra , Will Hawkins , Xi Ruoyao , Xionghu Luo , Yannick Moy , Yixuan Chen , YunQiang Su , Yuri Gribov , bors[bot] <26634292+bors[bot]@users.noreply.github.com>, konglin1 , liuhongt , mtsamis Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/546/steps/1/logs/stdio - 2: rm -rf gccrs-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/546/steps/2/logs/stdio - 3: configure ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/546/steps/3/logs/stdio A new failure has been detected on builder gccrust-debian-i386 while building gccrust. Full details are available at: https://builder.sourceware.org/buildbot/#builders/27/builds/561 Build state: failed configure (failure) Revision: 24ff0b3e0c41e3997fb4c11736b8a412afbaadf3 Worker: debian-i386 Build Reason: (unknown) Blamelist: Aldy Hernandez , Alex Coplan , Alexander Monakov , Alexandre Oliva , Andre Vieira , Andrea Corallo , Andrew Carlotti , Andrew MacLeod , Andrew Pinski , Andrew Pinski , Andrew Stubbs , Antoni Boucher , Arnaud Charlet , Arsen Arsenović , Arthur Cohen , Bernhard Reutner-Fischer , Bernhard Reutner-Fischer , Björn Schäpers , Bob Duff , Boris Yakobowski , Cedric Landet , Cesar Philippidis , Charles-François Natali , Christoph Müllner , Christophe Lyon , Claire Dross , David Faust , David Malcolm , David Seifert , Dimitar Dimitrov , Eric Botcazou , Eric Gallager , Eugene Rozenfeld , Fei Gao , Florian Weimer , François Dumont , Frolov Daniil , GCC Administrator , Gaius Mulley , Gary Dismukes , Ghjuvan Lacambre , H.J. Lu , Hans-Peter Nilsson , Haochen Gui , Haochen Jiang , Harald Anlauf , Hongyu Wang , Hu, Lin1 , Iain Buclaw , Iain Sandoe , Ian Lance Taylor , Iskander Shakirzyanov , Jakob Hasse <0xja...@users.noreply.github.com>, Jakub Jelinek , Jason Merrill , Javier Miranda , Jeff Chapman II , Jeff Law , Jeff Law , Jia-Wei Chen , Jinyang He , Jiufu Guo , Joel Brobecker , Johannes Kliemann , John David Anglin , Jonathan Wakely , Joseph Myers , Josue Nava Bello , José Rui Faustino de Sousa , Ju-Zhe Zhong , Justin Squirek , Kewen Lin , Kewen.Lin , Kwok Cheung Yeung , Kyrylo Tkachov , Lewis Hyatt , Liaiss Merzougue , Lili Cui , Lulu Cheng , Maciej W. Rozycki , Marc Poulhiès , Marcel Vollweiler ,
Re: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)
Hi!
On 2022-12-15T12:50:44+0100, Jakub Jelinek via Gcc-patches
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
Re: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)
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 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
☺ Buildbot (GNU Toolchain): gccrust - build successful (master)
A restored build has been detected on builder gccrust-fedora-x86_64 while building gccrust. Full details are available at: https://builder.sourceware.org/buildbot/#builders/16/builds/547 Build state: build successful Revision: fe648fb91c51cb477cf0380105c0bb85796be2df Worker: bb1-2 Build Reason: (unknown) Blamelist: Aldy Hernandez , Alex Coplan , Alexander Monakov , Alexandre Oliva , Andre Vieira , Andrea Corallo , Andrew Carlotti , Andrew MacLeod , Andrew Pinski , Andrew Pinski , Andrew Stubbs , Antoni Boucher , Arnaud Charlet , Arsen Arsenović , Arthur Cohen , Bernhard Reutner-Fischer , Bernhard Reutner-Fischer , Björn Schäpers , Bob Duff , Boris Yakobowski , Cedric Landet , Cesar Philippidis , Charles-François Natali , Christoph Müllner , Christophe Lyon , Claire Dross , David Faust , David Malcolm , David Seifert , Dimitar Dimitrov , Eric Botcazou , Eric Gallager , Eugene Rozenfeld , Fei Gao , Florian Weimer , François Dumont , Frolov Daniil , GCC Administrator , Gaius Mulley , Gary Dismukes , Ghjuvan Lacambre , H.J. Lu , Hans-Peter Nilsson , Haochen Gui , Haochen Jiang , Harald Anlauf , Hongyu Wang , Hu, Lin1 , Iain Buclaw , Iain Sandoe , Ian Lance Taylor , Iskander Shakirzyanov , Jakob Hasse <0xja...@users.noreply.github.com>, Jakub Jelinek , Jason Merrill , Javier Miranda , Jeff Chapman II , Jeff Law , Jeff Law , Jia-Wei Chen , Jinyang He , Jiufu Guo , Joel Brobecker , Johannes Kliemann , John David Anglin , Jonathan Wakely , Joseph Myers , Josue Nava Bello , José Rui Faustino de Sousa , Ju-Zhe Zhong , Justin Squirek , Kewen Lin , Kewen.Lin , Kwok Cheung Yeung , Kyrylo Tkachov , Lewis Hyatt , Liaiss Merzougue , Lili Cui , Lulu Cheng , Maciej W. Rozycki , Marc Poulhiès , Marcel Vollweiler , Marek Polacek , Martin Jambor , Martin Liska , Max Filippov , Michael Collison , Nathan Sidwell , Nathaniel Shead , Patrick Bernardi , Patrick Palka , Paul Thomas , Paul-Antoine Arras , Philipp Tomsich , Piotr Trojanek , Prathamesh Kulkarni , Qing Zhao , Quentin Ochem , Rainer Orth , Ramana Radhakrishnan , Rasmus Villemoes , Richard Biener , Richard Purdie , Ronan Desplanques , Sam James , Sandra Loosemore , Scott Snyder , Sebastian Huber , Sebastian Pop , Siddhesh Poyarekar , Sinan , Srinath Parvathaneni , Stam Markianos-Wright , Steve Baird , Steve Kargl , Surya Kumari Jangala , Tamar Christina , Thomas Schwinge , Tobias Burnus , Torbjörn SVENSSON , Uros Bizjak , Vladimir N. Makarov , Weimin Pan , Wilco Dijkstra , Wilco Dijkstra , Will Hawkins , Xi Ruoyao , Xionghu Luo , Yannick Moy , Yixuan Chen , YunQiang Su , Yuri Gribov , bors[bot] <26634292+bors[bot]@users.noreply.github.com>, konglin1 , liuhongt , mtsamis Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/1/logs/stdio - 2: rm -rf gccrs-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/2/logs/stdio - 3: configure ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/3/logs/stdio - 4: make ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/4/logs/stdio - warnings (34): https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/4/logs/warnings__34_ - 5: make check ( warnings ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/5/logs/stdio - rust.sum: https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/5/logs/rust_sum - rust.log: https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/5/logs/rust_log - warnings (6): https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/5/logs/warnings__6_ - 6: grep unexpected rust.sum ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/6/logs/stdio - 7: prep ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/7/logs/stdio - 8: build bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/8/logs/stdio - 9: fetch bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/9/logs/stdio - 10: unpack bunsen.cpio.gz ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/10/logs/stdio - 11: pass .bunsen.source.gitname ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/11/logs/stdio - 12: pass .bunsen.source.gitdescribe ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/16/builds/547/steps/12/logs/stdio - 13:
[Bug rust/108111] Rust meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111 --- Comment #3 from Marc Poulhiès --- Thanks Jonathan for the suggestion. The lexer code still need some refactor because the Source type (2nd template argument to buffered_queue) is expected to have a next() method and is used with both a InputSource& and a TokenSource. I have a local patch but still need to use clang to check the fix first :) -- 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
