Repository navigation
Open
Labels
A-LTOArea: Link-time optimization (LTO)Area: Link-time optimization (LTO)C-bugCategory: This is a bug.Category: This is a bug.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️S-needs-reproStatus: This issue has no reproduction and needs a reproduction to make progress.Status: This issue has no reproduction and needs a reproduction to make progress.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Description
Code
Something in the standard library. We caught this in our integration pipeline.
Meta
rustc --version --verbose:
1.71.0-nightly (9c51cf7e7 2023-04-19) running on x86_64-apple-darwin
Error output
Building stage2 library artifacts (x86_64-apple-darwin -> x86_64-unknown-linux-gnu)
Compiling cc v1.0.77
Compiling core v0.0.0 (/opt/s/w/ir/x/w/fuchsia-third_party-rust/library/core)
Compiling libc v0.2.140
Compiling memchr v2.5.0
Compiling std v0.0.0 (/opt/s/w/ir/x/w/fuchsia-third_party-rust/library/std)
Compiling compiler_builtins v0.1.91
Compiling unwind v0.0.0 (/opt/s/w/ir/x/w/fuchsia-third_party-rust/library/unwind)
Compiling profiler_builtins v0.0.0 (/opt/s/w/ir/x/w/fuchsia-third_party-rust/library/profiler_builtins)
thread 'rustc' panicked at 'assertion failed: ptr::eq(context.tcx.gcx as *const _ as *const (),\n tcx.gcx as *const _ as *const ())', /opt/s/w/ir/x/w/fuchsia-third_party-rust/compiler/rustc_middle/src/ty/context/tls.rs:126:9
stack backtrace:
0: rust_begin_unwind
at ./library/std/src/panicking.rs:578:5
1: core::panicking::panic_fmt
at ./library/core/src/panicking.rs:67:14
2: core::panicking::panic
at ./library/core/src/panicking.rs:117:5
3: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::region_scope_tree, rustc_query_impl::plumbing::QueryCtxt>
4: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::region_scope_tree
5: <rustc_hir_typeck::fn_ctxt::FnCtxt>::resolve_rvalue_scopes
6: rustc_hir_typeck::typeck
7: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::typeck, rustc_query_impl::plumbing::QueryCtxt>
8: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck
9: rustc_hir_typeck::typeck_item_bodies
10: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::typeck_item_bodies, rustc_query_impl::plumbing::QueryCtxt>
11: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck_item_bodies
12: rustc_hir_analysis::check_crate
13: rustc_interface::passes::analysis
14: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::analysis, rustc_query_impl::plumbing::QueryCtxt>
15: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis
16: <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#4}>
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: rustc 1.71.0-nightly (9c51cf7e7 2023-04-19) running on x86_64-apple-darwin
note: compiler flags: --crate-type lib -C opt-level=3 -C embed-bitcode=no -C codegen-units=1 -C debuginfo=2 -Z unstable-options -C linker=/opt/s/w/ir/x/w/cipd/bin/clang++ -C link-arg=--target=x86_64-unknown-linux-gnu -C link-arg=--sysroot=/opt/s/w/ir/x/w/cipd/linux -C link-arg=-fuse-ld=lld -C link-arg=-Wl,--undefined-version -C symbol-mangling-version=legacy -Z unstable-options -Z unstable-options -Z macro-backtrace -C link-args=-Wl,-z,origin -C link-args=-Wl,-rpath,$ORIGIN/../lib -C split-debuginfo=unpacked -C prefer-dynamic -Z inline-mir -C embed-bitcode=yes -Z crate-attr=doc(html_root_url="https://doc.rust-lang.org/nightly/") -Z binary-dep-depinfo -Z force-unstable-if-unmarked
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
#0 [typeck] type-checking `num::flt2dec::to_shortest_exp_str`
#1 [typeck_item_bodies] type-checking all item bodies
#2 [analysis] running analysis passes on this crate
end of query stack
error: could not compile `core`
Link to full build output here.
Backtrace
stack backtrace:
0: rust_begin_unwind
at ./library/std/src/panicking.rs:578:5
1: core::panicking::panic_fmt
at ./library/core/src/panicking.rs:67:14
2: core::panicking::panic
at ./library/core/src/panicking.rs:117:5
3: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::region_scope_tree, rustc_query_impl::plumbing::QueryCtxt>
4: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::region_scope_tree
5: <rustc_hir_typeck::fn_ctxt::FnCtxt>::resolve_rvalue_scopes
6: rustc_hir_typeck::typeck
7: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::typeck, rustc_query_impl::plumbing::QueryCtxt>
8: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck
9: rustc_hir_typeck::typeck_item_bodies
10: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::typeck_item_bodies, rustc_query_impl::plumbing::QueryCtxt>
11: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::typeck_item_bodies
12: rustc_hir_analysis::check_crate
13: rustc_interface::passes::analysis
14: rustc_query_system::query::plumbing::try_execute_query::<rustc_query_impl::queries::analysis, rustc_query_impl::plumbing::QueryCtxt>
15: <rustc_query_impl::Queries as rustc_middle::ty::query::QueryEngine>::analysis
16: <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#4}>
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
Metadata
Metadata
Assignees
Labels
A-LTOArea: Link-time optimization (LTO)Area: Link-time optimization (LTO)C-bugCategory: This is a bug.Category: This is a bug.I-ICEIssue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️S-needs-reproStatus: This issue has no reproduction and needs a reproduction to make progress.Status: This issue has no reproduction and needs a reproduction to make progress.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
Activity
Nashenas88 commentedon Apr 19, 2023
This occurred after testing the change at commit 9c51cf7. This is also occurring only on our mac builder. So far only one instance.
[-]ICE while compiling the compiler[/-][+]ICE: assertion failed: ptr::eq(context.tcx.gcx as *const _ as *const (), tcx.gcx as *const _ as *const ()), compiler/rustc_middle/src/ty/context/tls.rs[/+]Noratrieb commentedon Apr 21, 2023
Are you able to consistently reproduce the issue, and only after that commit?
Noratrieb commentedon Apr 21, 2023
This is a sanity assertion that should never be hit. It implies that there are two global contexts in the compilation session, which makes no sense. It's entirely possible that stage2 rustc is getting miscompiled. Do you have any weird configs?
jyn514 commentedon Apr 21, 2023
@Nashenas88 if you are hitting this reliably, can you apply this diff and post the new ICE message? I'd expect it to show the same numerical values for both pointers.
Nashenas88 commentedon Apr 21, 2023
@jyn514 @Nilstrieb unfortunately this hasn't reproduced.
Our config.toml is generated. It can be seen here: https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket/8783352442962811473/+/u/generate_config.toml/raw_io.output_text
And these were the environment variables:
https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket/8783352442962811473/+/u/generate_environment/raw_io.output_text_environment_
jyn514 commentedon Apr 21, 2023
all those options look pretty reasonable; the only thing that stands out is that we don't test
lto = fat, but I'm not aware of it being broken.Noratrieb commentedon Apr 21, 2023
Why are you using fat LTO in the first place? Have you measured the performance impact (or binary size impact)? ThinLTO was measured to be faster: #103453
tmandry commentedon Apr 21, 2023
We were following #101403 and must've missed that that was using thin instead of fat, or just assumed fat would be faster. We can always switch to thin.
I wouldn't expect that to explain this assertion failure though, unless LLVM is just doing a memory corruption in rustc.EDIT: Oh, a miscompile in the LTO pipeline could certainly explain ittmandry commentedon Apr 21, 2023
Still though, I find it fairly alarming that there would be a miscompile in rustc using supported options.