Skip to content

Cross-compiling Rust to s390x yields a faulty toolchain #80810

Closed
@Jakob-Naucke

Description

@Jakob-Naucke

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:

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:

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

added
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
on Jan 8, 2021
rylev

rylev commented on Jan 8, 2021

@rylev
Member

Assigning P-high as discussed as part of the Prioritization Working Group procedure and removing I-prioritize.

added
P-highHigh priority
and removed
I-prioritizeIssue: Indicates that prioritization has been requested for this issue.
on Jan 8, 2021
cuviper

cuviper commented on Jan 8, 2021

@cuviper
Member

I believe that there is a problem specific to the cross-compilation with an s390x target.

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

cuviper commented on Jan 8, 2021

@cuviper
Member

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

camelid commented on Jan 8, 2021

@camelid
Member

I believe that there is a problem specific to the cross-compilation with an s390x target.

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.

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

cuviper commented on Jan 8, 2021

@cuviper
Member

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:

cargo bisect-rustc --start 2020-10-01 --end 2021-01-08 -- check

That's the merge for #79637, a revert, which doesn't really make sense to me...
cc @spastorino @nikomatsakis @Mark-Simulacrum

camelid

camelid commented on Jan 8, 2021

@camelid
Member

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

cuviper commented on Jan 8, 2021

@cuviper
Member

@camelid

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?

I think we do normalize to/from little endian, but it's possible something was missed.

cuviper

cuviper commented on Jan 8, 2021

@cuviper
Member

did you have cargo-bisect-rustc run clean in between each toolchain run?

Doesn't it use a new target dir by default? That seems implied by the option to --preserve-target anyway.

camelid

camelid commented on Jan 8, 2021

@camelid
Member

I think you're right – I forgot about that :)

spastorino

spastorino commented on Jan 11, 2021

@spastorino
Member

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

That's the merge for #79637, a revert, which doesn't really make sense to me...
cc @spastorino @nikomatsakis @Mark-Simulacrum

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.

39 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

C-bugCategory: This is a bug.O-SystemZTarget: SystemZ processors (s390x)P-highHigh priorityT-compilerRelevant to the compiler team, which will review and decide on the PR/issue.regression-from-stable-to-stablePerformance or correctness regression from one stable version to another.

Type

No type

Projects

No projects

Relationships

None yet

    Development

    No branches or pull requests

      Participants

      @alex@cuviper@spastorino@pnkfelix@nagisa

      Issue actions

        Cross-compiling Rust to s390x yields a faulty toolchain · Issue #80810 · rust-lang/rust