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

[Nashenas88]

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.

[Nashenas88]

This occurred after testing the change at commit 9c51cf7. This is also occurring only on our mac builder. So far only one instance.

[Noratrieb]

Are you able to consistently reproduce the issue, and only after that commit?

[Noratrieb]

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]

@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.

diff --git a/compiler/rustc_middle/src/ty/context/tls.rs b/compiler/rustc_middle/src/ty/context/tls.rs
index fb0d909307e..f2a93ea7e25 100644
--- a/compiler/rustc_middle/src/ty/context/tls.rs
+++ b/compiler/rustc_middle/src/ty/context/tls.rs
@@ -126,7 +126,7 @@ pub fn with_related_context<'tcx, F, R>(tcx: TyCtxt<'tcx>, f: F) -> R
         assert!(ptr::eq(
             context.tcx.gcx as *const _ as *const (),
             tcx.gcx as *const _ as *const ()
-        ));
+        ), "{:?} != {:?}", context.tcx.gcx as *const _, tcx.gcx as *const _);
 
         let context: &ImplicitCtxt<'_, '_> = unsafe { mem::transmute(context) };
 

[Nashenas88]

@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]

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]

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]

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 it

[tmandry]

Still though, I find it fairly alarming that there would be a miscompile in rustc using supported options.