ICE while attempting to build docs for gba crate

[Lokathor]

Hello.

It's the first nightly with rustfmt since the thumbv4t PR merged, so I was able to update my nightly, so I figured I'd give a quick test of the gba crate and see if I could start updating it to using the new target. Hit some ICE.

For whatever reason, rustc is extremely unhappy with the non-default LLVM data layout.

Code

The code I tried to build is a repo:

git clone [email protected]:rust-console/gba.git
cd gba
cargo doc --open --target thumbv4t-none-eabi -Z build-std=core

However, since rustc was upset with the LLVM data layout, I presume that the target description itself is broken, and any code at all would always fail to build.

Meta

rustc --version --verbose:

pi@raspberrypi:~/gba $ rustc --version --verbose
rustc 1.47.0-nightly (d6953df14 2020-07-25)
binary: rustc
commit-hash: d6953df14657f5932270ad2b33bccafe6f39fad4
commit-date: 2020-07-25
host: armv7-unknown-linux-gnueabihf
release: 1.47.0-nightly
LLVM version: 10.0

Error output

error: internal compiler error: src/librustc_codegen_llvm/context.rs:159:13: data-layout for builtin `thumbv4t-none-eabi` target, `e-S64-p:32:32-i64:64-m:e-n32`, differs from LLVM default, `e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64`

thread 'rustc' panicked at 'Box<Any>', src/librustc_errors/lib.rs:915:9
note: run with `RUST_BACKTRACE=1` environment variable to display a 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.47.0-nightly (d6953df14 2020-07-25) running on armv7-unknown-linux-gnueabihf

note: compiler flags: -Z force-unstable-if-unmarked -C embed-bitcode=no -C debuginfo=2 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

error: aborting due to previous error

error: build failed

Note that no part of the target's data layout string (e-S64-p:32:32-i64:64-m:e-n32) actually contradicts the data layout string that rustc claims to be expecting (e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64), the target data layout string is simply not specifying every category, which is legal under LLVM's rules, but perhaps not legal under rustc's rules I guess.

Backtrace

(it looks like there's three things in here since i was trying to do a docs build, but i'll include the whole output) ``` pi@raspberrypi:~/gba $ RUST_BACKTRACE=1 cargo doc --open --target thumbv4t-none-eabi -Z build-std=core Compiling core v0.0.0 (/home/pi/.rustup/toolchains/nightly-armv7-unknown-linux-gnueabihf/lib/rustlib/src/rust/src/libcore) Compiling rustc-std-workspace-core v1.99.0 (/home/pi/.rustup/toolchains/nightly-armv7-unknown-linux-gnueabihf/lib/rustlib/src/rust/src/tools/rustc-std-workspace-core) error: internal compiler error: src/librustc_codegen_llvm/context.rs:159:13: data-layout for builtin `thumbv4t-none-eabi` target, `e-S64-p:32:32-i64:64-m:e-n32`, differs from LLVM default, `e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64`

thread 'rustc' panicked at 'Box', src/librustc_errors/lib.rs:915:9
stack backtrace:
Compiling compiler_builtins v0.1.32
error: internal compiler error: src/librustc_codegen_llvm/context.rs:159:13: data-layout for builtin thumbv4t-none-eabi target, e-S64-p:32:32-i64:64-m:e-n32, differs from LLVM default, e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64

thread 'rustc' panicked at 'Box', src/librustc_errors/lib.rs:915:9
stack backtrace:
error: internal compiler error: src/librustc_codegen_llvm/context.rs:159:13: data-layout for builtin thumbv4t-none-eabi target, e-S64-p:32:32-i64:64-m:e-n32, differs from LLVM default, e-m:e-p:32:32-Fi8-i64:64-v128:64:128-a:0:32-n32-S64

thread 'rustc' panicked at 'Box', src/librustc_errors/lib.rs:915:9
stack backtrace:
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:78
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:59
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
0: backtrace::backtrace::libunwind::trace
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
1: backtrace::backtrace::trace_unsynchronized
at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
2: std::sys_common::backtrace::_print_fmt
at src/libstd/sys_common/backtrace.rs:78
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:59
at src/libstd/sys_common/backtrace.rs:78
3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
at src/libstd/sys_common/backtrace.rs:59
4: core::fmt::write
at src/libcore/fmt/mod.rs:1117
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1508
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:62
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:198
9: std::panicking::default_hook
at src/libstd/panicking.rs:217
10: rustc_driver::report_ice
11: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:530
12: std::panicking::begin_panic
13: rustc_errors::HandlerInner::bug
14: rustc_errors::Handler::bug
15: rustc_middle::util::bug::opt_span_bug_fmt::{{closure}}
16: rustc_middle::ty::context::tls::with_opt::{{closure}}
17: rustc_middle::ty::context::tls::with_opt
18: rustc_middle::util::bug::opt_span_bug_fmt
19: rustc_middle::util::bug::bug_fmt
20: rustc_codegen_llvm::context::create_module
21: rustc_codegen_llvm::base::compile_codegen_unit::module_codegen
22: rustc_query_system::dep_graph::graph::DepGraph::with_task
23: rustc_codegen_llvm::base::compile_codegen_unit
4: core::fmt::write
24: rustc_codegen_ssa::base::codegen_crate
25: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
26: rustc_session::utils::::time
27: rustc_interface::passes::start_codegen
28: rustc_middle::ty::context::tls::enter_global
29: rustc_interface::queries::Queries::ongoing_codegen
30: rustc_interface::queries::::enter
31: rustc_span::with_source_map
32: rustc_interface::interface::create_compiler_and_run
33: scoped_tls::ScopedKey::set
note: Some details are omitted, run with RUST_BACKTRACE=full for a verbose backtrace.

4: core::fmt::write
at src/libcore/fmt/mod.rs:1117
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

5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1508
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:62
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:198
9: std::panicking::default_hook
at src/libstd/panicking.rs:217
10: rustc_driver::report_ice
11: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:530
12: std::panicking::begin_panic
13: rustc_errors::HandlerInner::bug
14: rustc_errors::Handler::bug
15: rustc_middle::util::bug::opt_span_bug_fmt::{{closure}}
16: rustc_middle::ty::context::tls::with_opt::{{closure}}
17: rustc_middle::ty::context::tls::with_opt
18: rustc_middle::util::bug::opt_span_bug_fmt
19: rustc_middle::util::bug::bug_fmt
20: rustc_codegen_llvm::context::create_module
21: rustc_codegen_llvm::base::compile_codegen_unit::module_codegen
22: rustc_query_system::dep_graph::graph::DepGraph::with_task
23: rustc_codegen_llvm::base::compile_codegen_unit
24: rustc_codegen_ssa::base::codegen_crate
25: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
26: rustc_session::utils::::time
27: rustc_interface::passes::start_codegen
28: rustc_middle::ty::context::tls::enter_global
29: rustc_interface::queries::Queries::ongoing_codegen
30: rustc_interface::queries::::enter
31: rustc_span::with_source_map
32: rustc_interface::interface::create_compiler_and_run
33: scoped_tls::ScopedKey::set
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.47.0-nightly (d6953df 2020-07-25) running on armv7-unknown-linux-gnueabihf

note: compiler flags: -Z force-unstable-if-unmarked -C embed-bitcode=no -C debuginfo=2 --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
at src/libcore/fmt/mod.rs:1117
5: std::io::Write::write_fmt
at src/libstd/io/mod.rs:1508
6: std::sys_common::backtrace::_print
at src/libstd/sys_common/backtrace.rs:62
7: std::sys_common::backtrace::print
at src/libstd/sys_common/backtrace.rs:49
8: std::panicking::default_hook::{{closure}}
at src/libstd/panicking.rs:198
9: std::panicking::default_hook
at src/libstd/panicking.rs:217
10: rustc_driver::report_ice
11: std::panicking::rust_panic_with_hook
at src/libstd/panicking.rs:530
note: rustc 1.47.0-nightly (d6953df 2020-07-25) running on armv7-unknown-linux-gnueabihf
12: std::panicking::begin_panic
13: rustc_errors::HandlerInner::bug

14: rustc_errors::Handler::bug
15: rustc_middle::util::bug::opt_span_bug_fmt::{{closure}}
16: rustc_middle::ty::context::tls::with_opt::{{closure}}
17: rustc_middle::ty::context::tls::with_opt
18: rustc_middle::util::bug::opt_span_bug_fmt
note: compiler flags: -Z force-unstable-if-unmarked -C embed-bitcode=no -C debuginfo=2 --crate-type lib
19: rustc_middle::util::bug::bug_fmt
20: rustc_codegen_llvm::context::create_module
21: rustc_codegen_llvm::base::compile_codegen_unit::module_codegen
22: rustc_query_system::dep_graph::graph::DepGraph::with_task

23: rustc_codegen_llvm::base::compile_codegen_unit
24: rustc_codegen_ssa::base::codegen_crate
25: <rustc_codegen_llvm::LlvmCodegenBackend as rustc_codegen_ssa::traits::backend::CodegenBackend>::codegen_crate
note: some of the compiler flags provided by cargo are hidden
26: rustc_session::utils::::time
27: rustc_interface::passes::start_codegen
28: rustc_middle::ty::context::tls::enter_global
29: rustc_interface::queries::Queries::ongoing_codegen

30: rustc_interface::queries::::enter
31: rustc_span::with_source_map
32: rustc_interface::interface::create_compiler_and_run
query stack during panic:
33: scoped_tls::ScopedKey::set
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.47.0-nightly (d6953df 2020-07-25) running on armv7-unknown-linux-gnueabihf

note: compiler flags: -Z force-unstable-if-unmarked -C embed-bitcode=no -C debuginfo=2 --crate-type lib

end of query stack
error: aborting due to previous error

note: some of the compiler flags provided by cargo are hidden
end of query stack

query stack during panic:
end of query stack
error: could not compile rustc-std-workspace-core.

To learn more, run the command again with --verbose.
warning: build failed, waiting for other jobs to finish...
error: aborting due to previous error

error: aborting due to previous error

error: build failed

</p>
</details>

[ketsuban]

Looks like #33446 is relevant (pointer snapped from #34960). Is the correct solution to just fix the data-layout for the new target?

[Lokathor]

That seems simplest to me, if T-compiler agrees.