[Bug rust/108087] -Wodr warnings in rust/rust-lang.cc (lang_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108087 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||marxin at gcc dot gnu.org Last reconfirmed||2022-12-14 Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Yes, I think it's a real issue. -- 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/106072] [13 Regression] Bogus -Wnonnull warning breaks rust bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106072 Jakub Jelinek changed: What|Removed |Added Component|ipa |rust CC||dkm at gcc dot gnu.org, ||gcc-rust 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/106072] [13 Regression] Bogus -Wnonnull warning breaks rust bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106072 --- Comment #14 from Jakub Jelinek --- Created attachment 54084 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54084&action=edit gcc13-pr106072.patch Untested fix. -- 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] rust: Fix up aarch64-linux bootstrap [PR106072]
Hi! Bootstrap fails on aarch64-linux and some other arches with: .../gcc/rust/parse/rust-parse-impl.h: In member function ‘Rust::AST::ClosureParam Rust::Parser::parse_closure_param() [with ManagedTokenSource = Rust::Lexer]’: .../gcc/rust/parse/rust-parse-impl.h:8916:49: error: ‘this’ pointer is null [-Werror=nonnull] The problem is that while say on x86_64-linux the side-effects in the arguments are evaluated from last argument to first, on aarch64-linux it is the other way around, from first to last. The C++ I believe even in C++17 makes the evaluation of those side-effects unordered (indeterminately sequenced with no interleaving), so that is fine. But, when the call in return statement is evaluated from first to last, std::move (pattern) happens before pattern->get_locus () and the former will make pattern (std::unique_ptr) a wrapper object around nullptr, so dereferencing it later to call get_locus () on it is invalid. The following patch fixes that, ok for trunk? 2022-12-14 Jakub Jelinek PR rust/106072 * parse/rust-parse-impl.h (parse_closure_param): Store pattern->get_locus () in a temporary before std::move (pattern) is invoked. --- gcc/rust/parse/rust-parse-impl.h.jj 2022-12-13 16:50:12.708093521 +0100 +++ gcc/rust/parse/rust-parse-impl.h2022-12-14 09:50:31.73932 +0100 @@ -8912,8 +8912,9 @@ Parser::parse_closur } } - return AST::ClosureParam (std::move (pattern), pattern->get_locus (), - std::move (type), std::move (outer_attrs)); + Location loc = pattern->get_locus (); + return AST::ClosureParam (std::move (pattern), loc, std::move (type), + std::move (outer_attrs)); } // Parses a grouped or tuple expression (disambiguates). Jakub -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug rust/108087] -Wodr warnings in rust/rust-lang.cc (lang_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108087 Arthur Cohen changed: What|Removed |Added CC||arthur.cohen at embecosm dot com --- Comment #4 from Arthur Cohen --- Thanks everyone, this is indeed a real issue and a mishap on our part. It's due to our const evaluator, which was ported over from the C++ frontend, defining another lang_type struct similar to what is the C++ one. I'm working on fixing it. I've opened up https://github.com/Rust-GCC/gccrs/issues/1702 and will report progress -- 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: [PATCH] rust: Fix up aarch64-linux bootstrap [PR106072]
Hi Jakub, On 12/14/22 10:14, Jakub Jelinek via Gcc-rust wrote: Hi! Bootstrap fails on aarch64-linux and some other arches with: .../gcc/rust/parse/rust-parse-impl.h: In member function ‘Rust::AST::ClosureParam Rust::Parser::parse_closure_param() [with ManagedTokenSource = Rust::Lexer]’: .../gcc/rust/parse/rust-parse-impl.h:8916:49: error: ‘this’ pointer is null [-Werror=nonnull] The problem is that while say on x86_64-linux the side-effects in the arguments are evaluated from last argument to first, on aarch64-linux it is the other way around, from first to last. The C++ I believe even in C++17 makes the evaluation of those side-effects unordered (indeterminately sequenced with no interleaving), so that is fine. But, when the call in return statement is evaluated from first to last, std::move (pattern) happens before pattern->get_locus () and the former will make pattern (std::unique_ptr) a wrapper object around nullptr, so dereferencing it later to call get_locus () on it is invalid. The following patch fixes that, ok for trunk? 2022-12-14 Jakub Jelinek PR rust/106072 * parse/rust-parse-impl.h (parse_closure_param): Store pattern->get_locus () in a temporary before std::move (pattern) is invoked. --- gcc/rust/parse/rust-parse-impl.h.jj 2022-12-13 16:50:12.708093521 +0100 +++ gcc/rust/parse/rust-parse-impl.h2022-12-14 09:50:31.73932 +0100 @@ -8912,8 +8912,9 @@ Parser::parse_closur } } - return AST::ClosureParam (std::move (pattern), pattern->get_locus (), - std::move (type), std::move (outer_attrs)); + Location loc = pattern->get_locus (); + return AST::ClosureParam (std::move (pattern), loc, std::move (type), + std::move (outer_attrs)); } // Parses a grouped or tuple expression (disambiguates). Jakub Thanks :) this looks good to me. We already have that issue fixed in our upstream dev branch, by this PR: https://github.com/Rust-GCC/gccrs/pull/1619 but we have yet to update GCC's master with our upstream dev branch, so in the meantime feel free to apply your patch. When I'll get to updating master, I'm expecting these kinds of tiny conflicts and we'll deal with them. Thanks a lot for working on this and sorry that my tardiness in updating has caused a duplication of efforts. All the best, -- Arthur Cohen Toolchain Engineer Embecosm GmbH Geschäftsführer: Jeremy Bennett Niederlassung: Nürnberg Handelsregister: HR-B 36368 www.embecosm.de Fürther Str. 27 90429 Nürnberg Tel.: 091 - 128 707 040 Fax: 091 - 128 707 077 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
[Bug rust/108084] AArch64 Linux bootstrap failure in rust
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108084 Thomas Schwinge changed: What|Removed |Added CC||gcc-rust at gcc dot gnu.org, ||tschwinge at gcc dot gnu.org Keywords|diagnostic | Component|c++ |rust See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=106072| --- Comment #9 from Thomas Schwinge --- Per PR106072, this actually is a GCC/Rust issue, not C++ diagnostic. -- 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/106072] [13 Regression] Bogus -Wnonnull warning breaks rust bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106072 Thomas Schwinge changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=108084| -- 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/106072] [13 Regression] -Wnonnull warning breaks rust bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106072 Thomas Schwinge changed: What|Removed |Added See Also||https://github.com/Rust-GCC ||/gccrs/pull/1619 CC||tschwinge at gcc dot gnu.org Blocks|95507 | Summary|[13 Regression] Bogus |[13 Regression] -Wnonnull |-Wnonnull warning breaks|warning breaks rust |rust bootstrap |bootstrap Keywords|diagnostic | --- Comment #15 from Thomas Schwinge --- Thanks, Jakub! So, an actual GCC/Rust issue, not PR95507 "(Wnonnull) - [meta-bug] bogus/missing -Wnonnull". Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 [Bug 95507] [meta-bug] bogus/missing -Wnonnull -- 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/106072] [13 Regression] -Wnonnull warning breaks rust bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106072 --- Comment #16 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:95dc11475dac06b5eecd904079de8aa94827a36a commit r13-4697-g95dc11475dac06b5eecd904079de8aa94827a36a Author: Jakub Jelinek Date: Wed Dec 14 11:35:22 2022 +0100 rust: Fix up aarch64-linux bootstrap [PR106072] Bootstrap fails on aarch64-linux and some other arches with: .../gcc/rust/parse/rust-parse-impl.h: In member function âRust::AST::ClosureParam Rust::Parser::parse_closure_param() [with ManagedTokenSource = Rust::Lexer]â: .../gcc/rust/parse/rust-parse-impl.h:8916:49: error: âthisâ pointer is null [-Werror=nonnull] The problem is that while say on x86_64-linux the side-effects in the arguments are evaluated from last argument to first, on aarch64-linux it is the other way around, from first to last. The C++ I believe even in C++17 makes the evaluation of those side-effects unordered (indeterminately sequenced with no interleaving), so that is fine. But, when the call in return statement is evaluated from first to last, std::move (pattern) happens before pattern->get_locus () and the former will make pattern (std::unique_ptr) a wrapper object around nullptr, so dereferencing it later to call get_locus () on it is invalid. 2022-12-14 Jakub Jelinek PR rust/106072 * parse/rust-parse-impl.h (parse_closure_param): Store pattern->get_locus () in a temporary before std::move (pattern) is invoked. -- 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: [PATCH] rust: Fix up aarch64-linux bootstrap [PR106072]
> -Original Message- > From: Gcc-patches bounces+kyrylo.tkachov=arm@gcc.gnu.org> On Behalf Of Arthur Cohen > Sent: Wednesday, December 14, 2022 10:05 AM > To: Jakub Jelinek ; gcc-rust@gcc.gnu.org; gcc- > patc...@gcc.gnu.org > Subject: Re: [PATCH] rust: Fix up aarch64-linux bootstrap [PR106072] > > Hi Jakub, > > On 12/14/22 10:14, Jakub Jelinek via Gcc-rust wrote: > > Hi! > > > > Bootstrap fails on aarch64-linux and some other arches with: > > .../gcc/rust/parse/rust-parse-impl.h: In member function > ‘Rust::AST::ClosureParam > Rust::Parser::parse_closure_param() [with > ManagedTokenSource = Rust::Lexer]’: > > .../gcc/rust/parse/rust-parse-impl.h:8916:49: error: ‘this’ pointer is null > > [- > Werror=nonnull] > > The problem is that while say on x86_64-linux the side-effects in the > > arguments are evaluated from last argument to first, on aarch64-linux > > it is the other way around, from first to last. The C++ I believe even > > in C++17 makes the evaluation of those side-effects unordered > > (indeterminately sequenced with no interleaving), so that is fine. > > But, when the call in return statement is evaluated from first to > > last, std::move (pattern) happens before pattern->get_locus () and > > the former will make pattern (std::unique_ptr) a wrapper object around > > nullptr, so dereferencing it later to call get_locus () on it is invalid. > > > > The following patch fixes that, ok for trunk? FWIW, with this patch my aarch64 bootstrap progressed past the previous point of failure (it's currently in stage 3). Thanks, Kyrill > > > > 2022-12-14 Jakub Jelinek > > > > PR rust/106072 > > * parse/rust-parse-impl.h (parse_closure_param): Store > > pattern->get_locus () in a temporary before std::move (pattern) is > > invoked. > > > > --- gcc/rust/parse/rust-parse-impl.h.jj 2022-12-13 > 16:50:12.708093521 +0100 > > +++ gcc/rust/parse/rust-parse-impl.h2022-12-14 09:50:31.73932 > +0100 > > @@ -8912,8 +8912,9 @@ Parser::parse_closur > > } > > } > > > > - return AST::ClosureParam (std::move (pattern), pattern->get_locus (), > > - std::move (type), std::move (outer_attrs)); > > + Location loc = pattern->get_locus (); > > + return AST::ClosureParam (std::move (pattern), loc, std::move (type), > > + std::move (outer_attrs)); > > } > > > > // Parses a grouped or tuple expression (disambiguates). > > > > Jakub > > > > Thanks :) this looks good to me. We already have that issue fixed in our > upstream dev branch, by this PR: > > https://github.com/Rust-GCC/gccrs/pull/1619 > > but we have yet to update GCC's master with our upstream dev branch, so > in the meantime feel free to apply your patch. When I'll get to updating > master, I'm expecting these kinds of tiny conflicts and we'll deal with > them. > > Thanks a lot for working on this and sorry that my tardiness in updating > has caused a duplication of efforts. > > All the best, > > -- > Arthur Cohen > > Toolchain Engineer > > Embecosm GmbH > > Geschäftsführer: Jeremy Bennett > Niederlassung: Nürnberg > Handelsregister: HR-B 36368 > www.embecosm.de > > Fürther Str. 27 > 90429 Nürnberg > > > Tel.: 091 - 128 707 040 > Fax: 091 - 128 707 077 -- Gcc-rust mailing list Gcc-rust@gcc.gnu.org https://gcc.gnu.org/mailman/listinfo/gcc-rust
[Bug rust/108087] -Wodr warnings in rust/rust-lang.cc (lang_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108087 Arthur Cohen changed: What|Removed |Added CC||cohenarthur at gcc dot gnu.org See Also||https://github.com/Rust-GCC ||/gccrs/issues/1702 -- 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/108087] -Wodr warnings in rust/rust-lang.cc (lang_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108087 Arthur Cohen changed: What|Removed |Added Status|NEW |ASSIGNED -- 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/108087] -Wodr warnings in rust/rust-lang.cc (lang_type)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108087 Thomas Schwinge changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |cohenarthur at gcc dot gnu.org CC||tschwinge 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/108102] New: rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 Bug ID: 108102 Summary: rust bootstrap comparison failure on s390x-linux-gnu Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rust Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org Target Milestone: --- seen with trunk 20221214 on s390x-linux-gnu: make[5]: Leaving directory '/<>/build' Comparing stages 2 and 3 Bootstrap comparison failure! gcc/rust/rust-hir-trait-resolve.o differs make[4]: *** [Makefile:31113: compare] Error 1 full build log at https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test/+build/24937231 -- 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/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 Matthias Klose changed: What|Removed |Added Target||s390x-linux-gnu -- 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/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- So what are the differences in stage2-gcc/rust/rust-hir-trait-resolve.o vs. stage3-gcc/rust/rust-hir-trait-resolve.o (or prev-gcc/ vs. gcc/ if it was moved back already)? -- 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] New: Rust meets clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111 Bug ID: 108111 Summary: Rust meets clang 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: --- Since the new Rust code landed in gcc, I thought I'd give it compile with clang. The following 14 warning messages were produced: ./../trunk.d1/gcc/rust/ast/rust-item.h:2186:23: warning: 'as_string' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] ../../trunk.d1/gcc/rust/ast/rust-item.h:2189:16: warning: 'accept_vis' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] ../../trunk.d1/gcc/rust/ast/rust-item.h:2191:12: warning: 'get_locus' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] ../../trunk.d1/gcc/rust/ast/rust-item.h:2196:8: warning: 'mark_for_strip' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] ../../trunk.d1/gcc/rust/ast/rust-item.h:2197:8: warning: 'is_marked_for_strip' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] ../../trunk.d1/gcc/rust/ast/rust-pattern.h:894:12: warning: 'get_locus' overrides a member function but is not marked 'override' [-Winconsistent-missing-override] ../../trunk.d1/gcc/rust/hir/tree/rust-hir-type.h:35:8: warning: private field 'in_parens' is not used [-Wunused-private-field] ../../trunk.d1/gcc/rust/lex/rust-lex.h:156:10: warning: explicitly defaulted move assignment operator is implicitly deleted [-Wdefaulted-function-deleted] ../../trunk.d1/gcc/rust/parse/rust-parse-impl.h:14918:23: warning: operator '?:' has lower precedence than '<<'; '<<' will be evaluated first [-Wparentheses] ../../trunk.d1/gcc/rust/typecheck/rust-substitution-mapper.h:332:19: warning: private field 'concrete' is not used [-Wunused-private-field] ../../trunk.d1/gcc/rust/typecheck/rust-tyty-call.h:140:31: warning: private field 'context' is not used [-Wunused-private-field] ../../trunk.d1/gcc/rust/typecheck/rust-tyty-call.h:83:31: warning: private field 'context' is not used [-Wunused-private-field] /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/new_allocator.h:181:4: warning: destructor called on non-final 'Rust::TyTy::TypeBoundPredicate' that has virtual functions but non-virtual destructor [-Wdelete-non-abstract-non-virtual-dtor] /usr/bin/../lib/gcc/x86_64-redhat-linux/12/../../../../include/c++/12/bits/stl_construct.h:151:7: warning: destructor called on non-final 'Rust::TyTy::TypeBoundPredicate' that has virtual functions but non-virtual destructor [-Wdelete-non-abstract-non-virtual-dtor] Some, all or none of these might be worth fixing. -- 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/108113] New: Rust and --enable-link-serialization=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113 Bug ID: 108113 Summary: Rust and --enable-link-serialization=1 Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rust Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org Target Milestone: --- Seems rust/Make-lang.in doesn't have link serialization support, I bet that must break --enable-link-serialization=1 builds with rust enabled. See r11-5142-gd326ebc94f3b2b0d962fb9e253564b39106a10da r11-5190-ga774a6a2fbeaf7cbcb7a7afe433418f2d740b45b commits what has been changed for other FEs. The first change introduced some stuff that the second one reverted, so what is needed in rust/Make-lang.in is basically rust.serial = rust1$(exeext) and making rust1$(exeext) depend on $(rust.prev) The generic code will ensure to fill in rust.prev to some other *.serial and set some other *.prev to rust.serial as needed. -- 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/108113] Rust and --enable-link-serialization=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113 Marc Poulhiès changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |dkm at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-12-14 Ever confirmed|0 |1 --- Comment #1 from Marc Poulhiès --- Thanks Jakub! I'll fix that, thanks for the detailed report -- 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/108113] Rust and --enable-link-serialization=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113 Marc Poulhiès changed: What|Removed |Added See Also||https://github.com/Rust-GCC ||/gccrs/pull/1704 -- 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 --- Comment #1 from Marc Poulhiès --- Hello David, Looking at the errors, most of them are trivial to fix. 1-6: missing 'override'. 9: not present in most recent dev branch on github, can be ignored as it will disappear when we update the gcc master branch with latest code. 13-14: class is missing a virtual dtor 7,10-12: unused variables I'll need to read a bit more about the 8 (default move assignment op being deleted). I've a first patch that addresses most of the warnings, but I'm missing the last one. If Arthur (or someone else) doesn't beat me to it, I'll have a fix shortly -- 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 --- Comment #2 from Jonathan Wakely --- (In reply to Marc Poulhiès from comment #1) > I'll need to read a bit more about the 8 (default move assignment op being > deleted). Lexer has this member: buffered_queue input_queue; That has a member of type InputSource& which means it is not assignable, so Lexer is not assignable either. Are you sure you want a reference there? Using std::reference_wrapper would work without needing to change buffered_queue. -- 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
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 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
>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_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 --gi
Re: Make '-frust-incomplete-and-experimental-compiler-do-not-use' a 'Common' option (was: Rust front-end patches v4)
On Wed, Dec 14, 2022 at 11:58 PM Thomas Schwinge
wrote:
>
> Hi!
>
> 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
>
> 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
--
Gcc-rust mailing list
Gcc-rust@gcc.gnu.org
https://gcc.gnu.org/mailman/listinfo/gcc-rust
