Summary: | dev-lang/rust-1.75.0-r1[lto] fails to compile on arm64 - error: could not compile memchr | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Leonid Kopylov <leonchik1976> |
Component: | Current packages | Assignee: | Gentoo Rust Project <rust> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arm64, eschwartz, matoro_gentoo, navi, parona, randy, rust |
Priority: | Normal | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=924396 https://github.com/gentoo/gentoo/pull/35334 https://github.com/rust-lang/rust/issues/121124 https://bugs.gentoo.org/show_bug.cgi?id=923278 https://github.com/gentoo/gentoo/pull/35796 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 618550 | ||
Attachments: |
build.log.xz
ICE message |
Description
Leonid Kopylov
2024-02-11 16:58:13 UTC
Created attachment 884746 [details]
build.log.xz
Caused by: process didn't exit successfully: `CARGO=/var/tmp/notmpfs/portage/dev-lang/rust-1.75.0-r1/work/rust-stage0/bin/cargo CARGO_CRATE_NAME=pkg_config CARGO_MANIFEST_DIR=/var/tmp/notmpfs/portage/dev-lang/rust-1.75.0-r1/work/rustc-1.75.0-src/vendor/pkg-config CARGO_PKG_AUTHORS='Alex Crichton <alex@alexcrichton.com>' CARGO_PKG_DESCRIPTION='A library to run the pkg-config system tool at build time in order to be used in Cargo build scripts. ' CARGO_PKG_HOMEPAGE='' CARGO_PKG_LICENSE='MIT OR Apache-2.0' CARGO_PKG_LICENSE_FILE='' CARGO_PKG_NAME=pkg-config CARGO_PKG_README=README.md CARGO_PKG_REPOSITORY='https://github.com/rust-lang/pkg-config-rs' CARGO_PKG_RUST_VERSION=1.30 CARGO_PKG_VERSION=0.3.27 CARGO_PKG_VERSION_MAJOR=0 CARGO_PKG_VERSION_MINOR=3 CARGO_PKG_VERSION_PATCH=27 CARGO_PKG_VERSION_PRE='' LD_LIBRARY_PATH='/var/tmp/notmpfs/portage/dev-lang/rust-1.75.0-r1/work/rustc-1.75.0-src/build/aarch64-unknown-linux-gnu/stage2-tools/release/deps:/var/tmp/notmpfs/portage/dev-lang/rust-1.75.0-r1/work/rustc-1.75.0-src/build/aarch64-unknown-linux-gnu/stage2/lib' /var/tmp/notmpfs/portage/dev-lang/rust-1.75.0-r1/work/rustc-1.75.0-src/build/bootstrap/debug/rustc --crate-name pkg_config /var/tmp/notmpfs/portage/dev-lang/rust-1.75.0-r1/work/rustc-1.75.0-src/vendor/pkg-config/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C embed-bitcode=no -C debug-assertions=off -Zunstable-options --check-cfg 'values(feature)' --check-cfg 'names()' --check-cfg 'values()' -C metadata=13f5ba3fd8dd7c11 -C extra-filename=-13f5ba3fd8dd7c11 --out-dir /var/tmp/notmpfs/portage/dev-lang/rust-1.75.0-r1/work/rustc-1.75.0-src/build/aarch64-unknown-linux-gnu/stage2-tools/release/deps -C linker=aarch64-unknown-linux-gnu-gcc -L dependency=/var/tmp/notmpfs/portage/dev-lang/rust-1.75.0-r1/work/rustc-1.75.0-src/build/aarch64-unknown-linux-gnu/stage2-tools/release/deps --cap-lints warn -Z binary-dep-depinfo` (exit status: 101) thread 'rustc' panicked at compiler/rustc_const_eval/src/interpret/place.rs:633:57: index out of bounds: the len is 1 but the index is 4294967040 stack backtrace: 0: rust_begin_unwind 1: core::panicking::panic_fmt 2: core::panicking::panic_bounds_check 3: <rustc_const_eval::interpret::eval_context::InterpCx<rustc_const_eval::const_eval::machine::CompileTimeInterpreter>>::write_immediate_no_validate::<rustc_const_eval::interpret::place::PlaceTy> 4: <rustc_const_eval::interpret::eval_context::InterpCx<rustc_const_eval::const_eval::machine::CompileTimeInterpreter>>::eval_rvalue_into_place 5: rustc_const_eval::const_eval::eval_queries::eval_in_interpreter 6: rustc_const_eval::const_eval::eval_queries::eval_to_allocation_raw_provider [... omitted 2 frames ...] 7: rustc_middle::query::plumbing::query_get_at::<rustc_query_system::query::caches::DefaultCache<rustc_middle::ty::ParamEnvAnd<rustc_middle::mir::interpret::GlobalId>, rustc_middle::query::erase::Erased<[u8; 24]>>> 8: rustc_const_eval::const_eval::eval_queries::eval_to_const_value_raw_provider [... omitted 2 frames ...] 9: rustc_middle::query::plumbing::query_get_at::<rustc_query_system::query::caches::DefaultCache<rustc_middle::ty::ParamEnvAnd<rustc_middle::mir::interpret::GlobalId>, rustc_middle::query::erase::Erased<[u8; 24]>>> 10: <rustc_middle::ty::context::TyCtxt>::const_eval_global_id 11: <rustc_middle::ty::context::TyCtxt>::const_eval_resolve 12: <rustc_const_eval::interpret::eval_context::InterpCx<rustc_const_eval::const_eval::machine::CompileTimeInterpreter>>::push_stack_frame 13: rustc_const_eval::const_eval::eval_queries::eval_in_interpreter 14: rustc_const_eval::const_eval::eval_queries::eval_to_allocation_raw_provider [... omitted 2 frames ...] 15: rustc_middle::query::plumbing::query_get_at::<rustc_query_system::query::caches::DefaultCache<rustc_middle::ty::ParamEnvAnd<rustc_middle::mir::interpret::GlobalId>, rustc_middle::query::erase::Erased<[u8; 24]>>> 16: rustc_const_eval::const_eval::eval_queries::eval_to_const_value_raw_provider [... omitted 2 frames ...] 17: rustc_middle::query::plumbing::query_get_at::<rustc_query_system::query::caches::DefaultCache<rustc_middle::ty::ParamEnvAnd<rustc_middle::mir::interpret::GlobalId>, rustc_middle::query::erase::Erased<[u8; 24]>>> 18: <rustc_middle::ty::context::TyCtxt>::const_eval_global_id 19: <rustc_middle::ty::context::TyCtxt>::const_eval_resolve 20: <rustc_const_eval::interpret::eval_context::InterpCx<rustc_const_eval::const_eval::machine::CompileTimeInterpreter>>::push_stack_frame 21: rustc_const_eval::const_eval::eval_queries::eval_in_interpreter 22: rustc_const_eval::const_eval::eval_queries::eval_to_allocation_raw_provider [... omitted 2 frames ...] 23: rustc_middle::query::plumbing::query_get_at::<rustc_query_system::query::caches::DefaultCache<rustc_middle::ty::ParamEnvAnd<rustc_middle::mir::interpret::GlobalId>, rustc_middle::query::erase::Erased<[u8; 24]>>> 24: rustc_const_eval::const_eval::eval_queries::eval_to_const_value_raw_provider [... omitted 2 frames ...] 25: rustc_middle::query::plumbing::query_get_at::<rustc_query_system::query::caches::DefaultCache<rustc_middle::ty::ParamEnvAnd<rustc_middle::mir::interpret::GlobalId>, rustc_middle::query::erase::Erased<[u8; 24]>>> 26: <rustc_middle::ty::context::TyCtxt>::const_eval_global_id 27: <rustc_middle::ty::context::TyCtxt>::const_eval_resolve 28: <rustc_middle::mir::consts::Const>::try_eval_scalar_int 29: <rustc_middle::mir::consts::Const>::try_eval_bits 30: <rustc_const_eval::transform::promote_consts::Validator>::validate_local 31: <core::iter::adapters::copied::Copied<core::slice::iter::Iter<rustc_const_eval::transform::promote_consts::Candidate>> as core::iter::traits::iterator::Iterator>::try_fold::<(), core::iter::traits::iterator::Iterator::find::check<rustc_const_eval::transform::promote_consts::Candidate, &mut rustc_const_eval::transform::promote_consts::validate_candidates::{closure#0}>::{closure#0}, core::ops::control_flow::ControlFlow<rustc_const_eval::transform::promote_consts::Candidate>> 32: <alloc::vec::Vec<rustc_const_eval::transform::promote_consts::Candidate> as alloc::vec::spec_from_iter::SpecFromIter<rustc_const_eval::transform::promote_consts::Candidate, core::iter::adapters::filter::Filter<core::iter::adapters::copied::Copied<core::slice::iter::Iter<rustc_const_eval::transform::promote_consts::Candidate>>, rustc_const_eval::transform::promote_consts::validate_candidates::{closure#0}>>>::from_iter 33: <rustc_const_eval::transform::promote_consts::PromoteTemps as rustc_middle::mir::MirPass>::run_pass 34: rustc_mir_transform::pass_manager::run_passes_inner 35: rustc_mir_transform::mir_promoted [... omitted 1 frame ...] 36: rustc_borrowck::mir_borrowck [... omitted 1 frame ...] 37: rustc_interface::passes::analysis [... omitted 1 frame ...] 38: <rustc_interface::queries::QueryResult<&rustc_middle::ty::context::GlobalCtxt>>::enter::<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#1}::{closure#2}::{closure#6}> 39: <scoped_tls::ScopedKey<rustc_span::SessionGlobals>>::set::<rustc_interface::interface::run_compiler<core::result::Result<(), rustc_span::ErrorGuaranteed>, rustc_driver_impl::run_compiler::{closure#1}>::{closure#0}, core::result::Result<(), rustc_span::ErrorGuaranteed>> note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace. error: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: please attach the file at `/var/tmp/notmpfs/portage/dev-lang/rust-1.75.0-r1/work/rustc-1.75.0-src/vendor/memchr/rustc-ice-2024-02-11T16_22_27-21317.txt` to your bug report note: compiler flags: --crate-type lib -C opt-level=3 -C embed-bitcode=no -Z unstable-options -C linker=aarch64-unknown-linux-gnu-gcc -C symbol-mangling-version=v0 -Z unstable-options -Z macro-backtrace -C split-debuginfo=off -Z binary-dep-depinfo -Z tls-model=initial-exec note: some of the compiler flags provided by cargo are hidden query stack during panic: #0 [eval_to_allocation_raw] const-evaluating + checking `core::num::<impl usize>::MAX` #1 [eval_to_const_value_raw] simplifying constant for the type system `core::num::<impl usize>::MAX` | = note: this failure-note originates in the macro `uint_impl` (in Nightly builds, run with -Z macro-backtrace for more info) #2 [eval_to_allocation_raw] const-evaluating + checking `core::num::<impl usize>::BITS` #3 [eval_to_const_value_raw] simplifying constant for the type system `core::num::<impl usize>::BITS` #4 [eval_to_allocation_raw] const-evaluating + checking `arch::all::memchr::USIZE_BYTES` #5 [eval_to_const_value_raw] simplifying constant for the type system `arch::all::memchr::USIZE_BYTES` #6 [mir_promoted] promoting constants in MIR for `arch::all::memchr::<impl at /rust/deps/memchr/src/arch/all/memchr.rs:40:1: 40:9>::find_raw` #7 [mir_borrowck] borrow-checking `arch::all::memchr::<impl at /rust/deps/memchr/src/arch/all/memchr.rs:40:1: 40:9>::find_raw` #8 [analysis] running analysis passes on this crate end of query stack Did not run successfully: exit status: 101 ... and so on system-llvm and system-bootstrap seem to have no effect, issue still occurs. This is caused by USE=lto, goes away without Thank you for the bug report! I see that the Rust error output is asking us to file a ticket with rust, and it asked us to attach the contents of the file /var/tmp/notmpfs/portage/dev-lang/rust-1.75.0-r1/work/rustc-1.75.0-src/vendor/memchr/rustc-ice-2024-02-11T16_22_27-21317.txt to the ticket. Do you think you could share that file? If you don't have the file from the exact original build but are able to reproduce the failure, the file might have a different name since it appears to encode a timestamp. (In reply to matoro from comment #4) > This is caused by USE=lto, goes away without Hello! Can I assume this means that you've been able to reproduce this issue as well? Is it also an aarch64 system? Created attachment 884866 [details]
ICE message
Reproduced under Qemu 8.1.5 aarch64 system chroot with
[ebuild U ~] dev-lang/rust-1.75.0-r1:stable/1.75::gentoo [1.74.1:stable/1.74::gentoo] USE="lto (-big-endian) -clippy -debug -dist -doc (-llvm-libunwind) (-miri) -nightly (-parallel-compiler) -profiler -rust-analyzer -rust-src -rustfmt -system-bootstrap -system-llvm -test -verify-sig -wasm" LLVM_TARGETS="(AArch64) -AMDGPU -ARC -ARM -AVR -BPF -CSKY -DirectX -Hexagon -Lanai -LoongArch -M68k -MSP430 -Mips -NVPTX -PowerPC -RISCV -SPIRV -Sparc -SystemZ -VE -WebAssembly -X86 -XCore -Xtensa" 0 KiB
Requested ICE file attached
(In reply to Randy Barlow from comment #6) > (In reply to matoro from comment #4) > > This is caused by USE=lto, goes away without > > Hello! Can I assume this means that you've been able to reproduce this issue > as well? Is it also an aarch64 system? Yes, this is specific to LTO on aarch64. I appear to lack permissions to set metadata on the ticket, but I opened https://github.com/rust-lang/rust/issues/121124 upstream about this. If someone has time and interest, it would probably be helpful if we could test the latest HEAD on the upstream master branch with LTO enabled on one of the affected architectures. Perhaps we can soon add a -9999 package for Rust to make this kind of testing easier. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4d17ee4b1582bb4355ca6437be4accf980fa8eda commit 4d17ee4b1582bb4355ca6437be4accf980fa8eda Author: Anna (navi) Figueiredo Gomes <navi@vlhl.dev> AuthorDate: 2024-02-14 23:06:07 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-02-15 13:52:42 +0000 profiles/arch/arm64/package.use.mask: Mask lto for ~dev-lang/rust-1.75.0 Bug: https://bugs.gentoo.org/924301 Signed-off-by: Anna (navi) Figueiredo Gomes <navi@vlhl.dev> Signed-off-by: Sam James <sam@gentoo.org> profiles/arch/arm64/package.use.mask | 4 ++++ 1 file changed, 4 insertions(+) In the upstream ticket, it sounds like using lto = "fat" (which is what our ebuild does) is not recommended. They seem to suggest trying lto = "thin" which they say is more tested. I see that we merged some changes that flip this to a hard off for 1.75, which is fine, so I think I might go suggest this change in the 1.76.0 PR that's open right now and maybe we can try again there (I do still think lto off by default is sensible, since it is generally off by default across all packages in Gentoo IME). Alright, I proposed thin LTO at https://github.com/gentoo/gentoo/pull/35272/files#r1491767742 for Rust 1.76.0. How do we feel about waiting for 1.76.0 to get merged to test LTO on these platforms again, vs. making a new 1.75.0-r* to try with 1.75? I'm happy to make a new 1.75 if we want that. Upstream would like to know if this issue is reproducible with nightly Rust using LLVM 18: https://github.com/rust-lang/rust/issues/121124#issuecomment-1952228591 If anyone here who is able to reproduce this can check that, that would be lovely. (In reply to Randy Barlow from comment #13) > Upstream would like to know if this issue is reproducible with nightly Rust > using LLVM 18: > https://github.com/rust-lang/rust/issues/121124#issuecomment-1952228591 > > If anyone here who is able to reproduce this can check that, that would be > lovely. I don't think this is feasible to check until we have dev-lang/rust-9999 wired up. (In reply to matoro from comment #14) > I don't think this is feasible to check until we have dev-lang/rust-9999 > wired up. I agree that that would make it much easier to check, but it may be possible to check by git cloning upstream and setting lto = "fat" in the config.toml manually (i.e., outside of the ebuild system). Certainly more work, but if anyone has the appetite I think they'd appreciate it. Still present on 1.76.0, please extend mask. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c4fea4d54461547fd1af6fb60796b99778a3d694 commit c4fea4d54461547fd1af6fb60796b99778a3d694 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-03-10 01:48:12 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-03-10 01:48:12 +0000 profiles/arch: broaden the Rust LTO mask for arm64 & powerpc matoro reports 1.76.0 is still hosed. Bug: https://bugs.gentoo.org/924301 Bug: https://bugs.gentoo.org/924396 Signed-off-by: Sam James <sam@gentoo.org> profiles/arch/arm64/package.use.mask | 2 +- profiles/arch/powerpc/package.use.mask | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d7f3dfefc2ab978d5d38b50d1e061c4a530d85f8 commit d7f3dfefc2ab978d5d38b50d1e061c4a530d85f8 Author: Randy Barlow <randy@electronsweatshop.com> AuthorDate: 2024-03-17 03:00:43 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-03-21 02:22:02 +0000 dev-lang/rust: Disable LTO by default and use thin We've had a few issues with lto on, and it isn't on by default generally among Gentoo packages, so this commit flips it to be off by default. Additionally, in an upstream ticket[0] it was suggested to use thin LTO rather than fat LTO, so this commit makes that adjustment as well. [0] https://github.com/rust-lang/rust/issues/121124 [sam: Note that there's a risk of miscompilations with non-thin LTO, per the upstream bug(s).] Bug: https://bugs.gentoo.org/924301 Signed-off-by: Randy Barlow <randy@electronsweatshop.com> Closes: https://github.com/gentoo/gentoo/pull/35796 Signed-off-by: Sam James <sam@gentoo.org> dev-lang/rust/{rust-1.76.0.ebuild => rust-1.76.0-r1.ebuild} | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) masked, reported upstream, nothing more to do here. |