Open Nashenas88 opened 1 year ago
This occurred after testing the change at commit 9c51cf7e. This is also occurring only on our mac builder. So far only one instance.
Are you able to consistently reproduce the issue, and only after that commit?
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?
@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) };
@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_textenvironment
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.
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
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
Still though, I find it fairly alarming that there would be a miscompile in rustc using supported options.
Code
Something in the standard library. We caught this in our integration pipeline.
Meta
rustc --version --verbose
:Error output
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::
4: ::region_scope_tree
5: ::resolve_rvalue_scopes
6: rustc_hir_typeck::typeck
7: rustc_query_system::query::plumbing::try_execute_query::
8: ::typeck
9: rustc_hir_typeck::typeck_item_bodies
10: rustc_query_system::query::plumbing::try_execute_query::
11: ::typeck_item_bodies
12: rustc_hir_analysis::check_crate
13: rustc_interface::passes::analysis
14: rustc_query_system::query::plumbing::try_execute_query::
15: ::analysis
16: >::enter::, 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.
```