[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
[Bug rust/108113] Rust and --enable-link-serialization=1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108113 --- Comment #6 from CVS Commits --- The master branch has been updated by Marc Poulhi?s : https://gcc.gnu.org/g:02c031088ac0bbf716aec52e027d615b7a5a572b commit r13-4804-g02c031088ac0bbf716aec52e027d615b7a5a572b Author: Marc Poulhiès Date: Wed Dec 14 21:29:13 2022 +0100 rust: fix link serialization [PR108113] The Make-lang.in was missing the link serialization support. PR rust/108113 gcc/rust * Make-lang.in (rust.serial): New variable. (rust1$(exeext)): Depend on $(rust.prev). Call LINK_PROGRESS. Signed-off-by: Marc Poulhiès -- 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 middle-end/108102] rust bootstrap comparison failure on s390x-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #15 from CVS Commits ---
The master branch has been updated by Stefan Schulze Frielinghaus
:
https://gcc.gnu.org/g:452db716d8debb6e09b85e4a0c0e73a047ed5c1d
commit r13-5964-g452db716d8debb6e09b85e4a0c0e73a047ed5c1d
Author: Stefan Schulze Frielinghaus
Date: Mon Feb 13 15:33:38 2023 +0100
IBM zSystems: Do not propagate scheduler state across basic blocks
[PR108102]
So far we propagate scheduler state across basic blocks within EBBs and
reset the state otherwise. In certain circumstances the entry block of
an EBB might be empty, i.e., no_real_insns_p is true. In those cases
scheduler state is not reset and subsequently wrong state is propagated
to following blocks of the same EBB.
Since the performance benefit of tracking state across basic blocks is
questionable on modern hardware, simply reset the state for each basic
block.
Fix also resetting f{p,x}d_longrunning.
gcc/ChangeLog:
PR target/108102
* config/s390/s390.cc (s390_bb_fallthru_entry_likely): Remove.
(struct s390_sched_state): Initialise to zero.
(s390_sched_variable_issue): For better debuggability also emit
the current side.
(s390_sched_init): Unconditionally reset scheduler state.
--
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 translation/108890] Translation mistakes 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108890 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9f9a7095d910379cd86ac45f81c79b363f859996 commit r13-6304-g9f9a7095d910379cd86ac45f81c79b363f859996 Author: Jakub Jelinek Date: Thu Feb 23 15:27:31 2023 +0100 c++: Fix up -fcontracts option description [PR108890] This translation PR mentioned the description is a little bit weird. 2023-02-23 Jakub Jelinek PR translation/108890 * c.opt (fcontracts): Fix description. -- 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 translation/108890] Translation mistakes 2023
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108890
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:7423f5b56ad436f51ac1b9defb954e2bdc5b06ab
commit r13-6307-g7423f5b56ad436f51ac1b9defb954e2bdc5b06ab
Author: Jakub Jelinek
Date: Thu Feb 23 23:26:43 2023 +0100
xtensa: Fix up fatal_error message strings in xtensa-dynconfig.c [PR108890]
The translation PR complains that these 4 messages from xtensa-dynconfig.c
are marked in po/gcc.pot as c-format (which doesn't allow %qs) while they
should be gcc-internal-format.
The problem is in the manual translation of the strings with _(),
that should be both unnecessary because fatal_error invokes _() on its
argument already, but also incorrect for the above reason, for
gcc-internal-format strings one should use G_("...") instead if really
needed.
The following patch drops those _("..."), tested by regenerating po/gcc.pot
to see they are now gcc-internal-format, but not really tested on xtensa
target.
2023-02-23 Jakub Jelinek
PR translation/108890
* config/xtensa/xtensa-dynconfig.c (xtensa_load_config): Drop _()s
around fatal_error format strings.
--
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
