Description
Code
I tried this code on s390x:
trait T1: {}
trait T2: {
type Foo: T1;
}
trait T3<T>: {
fn f(&self) -> T::Foo where T: T2;
}
fn main() {}
(originally discovered in and derived to make an MWE from gimli) with all of the following:
- rustup toolchains 1.50 (current beta) and 1.51 (current nightly)
- https://static.rust-lang.org/dist/2020-12-30/rust-beta-s390x-unknown-linux-gnu.tar.gz which is used as stage0 when compiling Rust
- Rust cross-compiled from the Git repository on master with
DEPLOY=1 ./src/ci/docker/run.sh dist-s390x-linux
on x86_64 and installed on s390x
I expected to see this happen: a successful compiler run, as is on x86_64
Instead, this happened:
error[E0220]: associated type `Foo` not found for `T`
--> demo.rs:6:23
|
6 | fn f(&self) -> T::Foo where T: T2;
| ^^^ associated type `Foo` not found
error: aborting due to previous error
For more information about this error, try `rustc --explain E0220`.
Furthermore, when building Rust with x.py
on s390x after the switch to the aforementioned 2020-12-30 stage0 (introduced in fe031180
), an ICE is claimed:
Output
$ RUST_BACKTRACE=1 ./x.py build
Updating only changed submodules
Submodules updated in 0.02 seconds
Finished dev [unoptimized + debuginfo] target(s) in 0.13s
Building stage0 std artifacts (s390x-unknown-linux-gnu -> s390x-unknown-linux-gnu)
Compiling core v0.0.0 (/home/fedora/rust/library/core)
error: internal compiler error: compiler/rustc_privacy/src/lib.rs:500:25: item Item { ident: #0, hir_id: HirId { owner: DefId(0:472 ~ core[5990]::num::flt2dec::{misc#0}), local_id: 0 }, attrs: [], kind: Use(Path { span: library/core/src/num/flt2dec/mod.rs:125:9: 125:70 (#0), res: Err, segments: [PathSegment { ident: self#0, hir_id: Some(HirId { owner: DefId(0:472 ~ core[5990]::num::flt2dec::{misc#0}), local_id: 1 }), res: Some(Err), args: None, infer_args: false }, PathSegment { ident: decoder#0, hir_id: Some(HirId { owner: DefId(0:472 ~ core[5990]::num::flt2dec::{misc#0}), local_id: 2 }), res: Some(Def(Mod, DefId(0:478 ~ core[5990]::num::flt2dec::decoder))), args: None, infer_args: false }] }, ListStem), vis: Spanned { node: Inherited, span: library/core/src/num/flt2dec/mod.rs:125:9: 125:9 (#0) }, span: library/core/src/num/flt2dec/mod.rs:125:1: 125:71 (#0) } with DefKind Struct
thread 'rustc' panicked at 'Box<Any>', compiler/rustc_errors/src/lib.rs:958:9
stack backtrace:
0: std::panicking::begin_panic
1: rustc_errors::HandlerInner::bug
2: rustc_errors::Handler::bug
3: rustc_middle::util::bug::opt_span_bug_fmt::{{closure}}
4: rustc_middle::ty::context::tls::with_opt::{{closure}}
5: rustc_middle::ty::context::tls::with_opt
6: rustc_middle::util::bug::opt_span_bug_fmt
7: rustc_middle::util::bug::bug_fmt
8: rustc_privacy::EmbargoVisitor::update_macro_reachable_def
9: rustc_privacy::EmbargoVisitor::update_macro_reachable
10: rustc_privacy::EmbargoVisitor::update_macro_reachable_def
11: rustc_privacy::EmbargoVisitor::update_macro_reachable
12: rustc_privacy::EmbargoVisitor::update_macro_reachable_def
13: rustc_privacy::EmbargoVisitor::update_macro_reachable
14: <rustc_privacy::EmbargoVisitor as rustc_hir::intravisit::Visitor>::visit_macro_def
15: rustc_privacy::privacy_access_levels
16: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::privacy_access_levels>::compute
17: rustc_query_system::dep_graph::graph::DepGraph<K>::with_eval_always_task
18: rustc_data_structures::stack::ensure_sufficient_stack
19: rustc_query_system::query::plumbing::get_query_impl
20: rustc_query_system::query::plumbing::ensure_query_impl
21: <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once
22: __rust_try.llvm.16454507701973609965
23: rustc_session::utils::<impl rustc_session::session::Session>::time
24: rustc_interface::passes::analysis
25: rustc_middle::ty::query::<impl rustc_query_system::query::config::QueryAccessors<rustc_middle::ty::context::TyCtxt> for rustc_middle::ty::query::queries::analysis>::compute
26: rustc_query_system::dep_graph::graph::DepGraph<K>::with_eval_always_task
27: rustc_data_structures::stack::ensure_sufficient_stack
28: rustc_query_system::query::plumbing::get_query_impl
29: rustc_interface::queries::<impl rustc_interface::interface::Compiler>::enter
30: rustc_span::with_source_map
31: rustc_interface::interface::create_compiler_and_run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
note: 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.50.0-beta.1 (05b602367 2020-12-29) running on s390x-unknown-linux-gnu
note: compiler flags: -Z macro-backtrace -Z binary-dep-depinfo -Z force-unstable-if-unmarked -C opt-level=3 -C embed-bitcode=no -C debuginfo=0 -C link-args=-Wl,-rpath,$ORIGIN/../lib -C prefer-dynamic --crate-type lib
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
#0 [privacy_access_levels] privacy access levels
#1 [analysis] running analysis passes on this crate
end of query stack
error: aborting due to previous error
error: could not compile `core`
To learn more, run the command again with --verbose.
command did not execute successfully: "/home/fedora/rust/build/s390x-unknown-linux-gnu/stage0/bin/cargo" "build" "--target" "s390x-unknown-linux-gnu" "-Zbinary-dep-depinfo" "-j" "4" "--release" "--features" "panic-unwind backtrace compiler-builtins-c" "--manifest-path" "/home/fedora/rust/library/test/Cargo.toml" "--message-format" "json-render-diagnostics"
expected success, got: exit code: 101
failed to run: /home/fedora/rust/build/bootstrap/debug/bootstrap build
Build completed unsuccessfully in 0:00:06
Rust compiled on s390x natively (immediately prior to that introduction) does not have this issue.
Since the Rust dists are built through cross-compilation for Tier 2 architectures, I believe that there is a problem specific to the cross-compilation with an s390x target.
Versions it worked on
It most recently worked on:
- rustup toolchain 1.49 (current stable)
- https://static.rust-lang.org/dist/2020-11-18/rust-beta-s390x-unknown-linux-gnu.tar.gz, the previous stage0
- Rust cross-compiled from the Git repository on tag 1.49.0
Versions with regression
e.g.
$ rustc --verbose --version
rustc 1.50.0-beta.5 (ff5998292 2021-01-05)
binary: rustc
commit-hash: ff59982926d98c8508008f0559f8a055260ac05e
commit-date: 2021-01-05
host: s390x-unknown-linux-gnu
release: 1.50.0-beta.5
Backtrace
no additional info for code example, ICE output had backtrace enabled
@rustbot modify labels: +regression-from-stable-to-beta -regression-untriaged
Activity
rylev commentedon Jan 8, 2021
Assigning P-high as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.
cuviper commentedon Jan 8, 2021
This has come up before when some part of the crate metadata is accidentally written in native-endian order -- so x86_64 rustc writes some little-endian data in the standard library rlibs, and s390x rustc reads that as big-endian.
cuviper commentedon Jan 8, 2021
I can reproduce this on RHEL 7 s390x, but not ppc64, so it would seem to be something other than endian order.
I will try to bisect this.
camelid commentedon Jan 8, 2021
I know you said based on testing it doesn't seem to be endian order that's causing this issue, but in general can't we just standardize on either little-endian or big-endian somehow?
cuviper commentedon Jan 8, 2021
searched nightlies: from nightly-2020-10-01 to nightly-2021-01-08
regressed nightly: nightly-2020-12-04
searched commits: from f4db9ff to 5be3f9f
regressed commit: b4def89
bisected with cargo-bisect-rustc v0.6.0
Host triple: s390x-unknown-linux-gnu
Reproduce with:
That's the merge for #79637, a revert, which doesn't really make sense to me...
cc @spastorino @nikomatsakis @Mark-Simulacrum
camelid commentedon Jan 8, 2021
Since this may be an rlib-related issue, did you have cargo-bisect-rustc run
clean
in between each toolchain run? Not sure if that could be the issue.cuviper commentedon Jan 8, 2021
@camelid
I think we do normalize to/from little endian, but it's possible something was missed.
cuviper commentedon Jan 8, 2021
Doesn't it use a new target dir by default? That seems implied by the option to
--preserve-target
anyway.camelid commentedon Jan 8, 2021
I think you're right – I forgot about that :)
spastorino commentedon Jan 11, 2021
Sorry, I don't have time right now to check this properly but a quick answer I can give you now is:
Could be that this was "tested" between my original PR was merged and the revert was merged and that's the reason why this "regressed"?. If so, it's not really a regression, my original PR fixed a very old issue and this revert, reverted it because it uncovered a different bug. In that case, #80732 will fix the issue again, maybe try the compiler generated for that PR and see what happens.
24 remaining items
Pin rust in s390x test job (#254)
cuviper commentedon Feb 22, 2021
Filed: https://bugs.llvm.org/show_bug.cgi?id=49322
That came from analysis of a stage1 testing failure in
ui/proc-macro/macro-rules-derive
, specifically from its macro here:rust/src/test/ui/proc-macro/auxiliary/first-second.rs
Lines 10 to 15 in 15598a8
I see
_attr
starts asTokenStream
handle 1,item
is 2, andtokens
gets 3. When the secondcollect
is called, that iterator is 12 bytes and now gets passed in LLVM IR as onei96
argument. That argument is converted in SystemZ back to being indirect on the stack, and this overflows to clobber_attr
to now look like handle 3 too. Then the_attr
drop panics:This might not be the only issue, but it was the first thing that I could positively isolate.
alex commentedon Feb 22, 2021
Excellent job with the debugging! Very impressive minimization.
cuviper commentedon Feb 23, 2021
On the Rust side, maybe
max_by_val_size
should be target-specific? LLVM is converting back to indirect in this case, so it's kind of a waste even if the bug is fixed.cuviper commentedon Mar 9, 2021
A fix for LLVM 49322 has landed, and I confirmed it does fix my minimization, but that Rust test still fails. It seems I must have minimized too much, so I'll have to step back and see what else went wrong.
cuviper commentedon Mar 9, 2021
Scratch that, I think something in my build failed to re-link, even though I thought I had cleaned it sufficiently. I couldn't figure out why my rustc was still clobbering stack in that test, while its build of llc did the right thing, so I ran a completely clean rebuild with the fix D97514 applied and now it is fine. I confirmed both on the regressed commit 0183b41 and on 1.50.0 final. So, yay! 🎉
I'll prepare a backport for rust-lang/llvm-project which we can update into 1.52-nightly, and then we can decide whether to also backport for 1.51-beta before that moves to stable.
uweigand commentedon Mar 10, 2021
@cuviper thanks for tracking this down! If possible, it would be great to the have the fix in 1.51 ...
cuviper commentedon Mar 11, 2021
@uweigand #82996 will pull the fix into 1.51-beta.
cuviper commentedon Mar 12, 2021
rustc 1.51.0-beta.5 (50b9553c1 2021-03-11)
rustc 1.52.0-nightly (4a8b6f708 2021-03-11)
I've confirmed that both are working on the original reproducer and on the
either
crate. I was also able to build a nativerustc
bootstrapped using that beta as the stage0 compiler.