Rust compiler generates unaligned code, crashes sparc64-linux

[glaubitz]

With version 1.28, rust no longer builds on sparc64-linux and fails at stage1:

     Running `/home/glaubitz/rustc/rustc-1.28.0+dfsg1/build/sparc64-unknown-linux-gnu/stage1-std/release/build/std-0b6c63ac16a949d9/build-script-build`
     Running `/home/glaubitz/rustc/rustc-1.28.0+dfsg1/build/sparc64-unknown-linux-gnu/stage1-std/release/build/compiler_builtins-b9409c16a4089d6c/build-script-build`
error: Could not compile `core`.

Caused by:
  failed to parse process output: `/home/glaubitz/rustc/rustc-1.28.0+dfsg1/build/bootstrap/debug/rustc --crate-name core libcore/lib.rs --error-format json --crate-type lib --emit=dep-info,link -C opt-level=2 -C metadata=b361570c84d1b2c9 -C extra-filename=-b361570c84d1b2c9 --out-dir /home/glaubitz/rustc/rustc-1.28.0+dfsg1/build/sparc64-unknown-linux-gnu/stage1-std/sparc64-unknown-linux-gnu/release/deps --target sparc64-unknown-linux-gnu -L dependency=/home/glaubitz/rustc/rustc-1.28.0+dfsg1/build/sparc64-unknown-linux-gnu/stage1-std/sparc64-unknown-linux-gnu/release/deps -L dependency=/home/glaubitz/rustc/rustc-1.28.0+dfsg1/build/sparc64-unknown-linux-gnu/stage1-std/release/deps -C link-args=-Wl,-z,relro --remap-path-prefix=/home/glaubitz/rustc/rustc-1.28.0+dfsg1=/usr/src/rustc-1.28.0` (exit code: 0)

Caused by:
  compiler stdout is not empty: `Did not run successfully: Ok(ExitStatus(ExitStatus(10)))`
command did not execute successfully: "/usr/bin/cargo" "build" "--target" "sparc64-unknown-linux-gnu" "-j" "32" "-v" "--release" "--features" "panic-unwind backtrace" "--manifest-path" "/home/glaubitz/rustc/rustc-1.28.0+dfsg1/src/libstd/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1091:9
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
             at libstd/panicking.rs:397
   6: bootstrap::compile::run_cargo
             at bootstrap/compile.rs:1091
   7: <bootstrap::compile::Std as bootstrap::builder::Step>::run
             at bootstrap/compile.rs:109
   8: bootstrap::builder::Builder::ensure
             at bootstrap/builder.rs:1107
   9: <bootstrap::compile::Test as bootstrap::builder::Step>::run
             at bootstrap/compile.rs:354
  10: bootstrap::builder::Builder::ensure
             at bootstrap/builder.rs:1107
  11: <bootstrap::compile::Rustc as bootstrap::builder::Step>::run
             at bootstrap/compile.rs:470
  12: bootstrap::builder::Builder::ensure
             at bootstrap/builder.rs:1107
  13: <bootstrap::compile::Assemble as bootstrap::builder::Step>::run
             at bootstrap/compile.rs:929
  14: bootstrap::builder::Builder::ensure
             at bootstrap/builder.rs:1107
  15: bootstrap::builder::Builder::compiler
             at bootstrap/builder.rs:570
  16: <bootstrap::compile::Std as bootstrap::builder::Step>::make_run
             at bootstrap/compile.rs:57
  17: bootstrap::builder::StepDescription::maybe_run
             at bootstrap/builder.rs:191
  18: bootstrap::builder::StepDescription::run
             at bootstrap/builder.rs:215
  19: bootstrap::builder::Builder::run_step_descriptions
             at bootstrap/builder.rs:562
  20: bootstrap::builder::Builder::execute_cli
             at bootstrap/builder.rs:552
  21: bootstrap::Build::build
             at bootstrap/lib.rs:450
  22: bootstrap::main
             at bootstrap/bin/main.rs:29
  23: std::rt::lang_start::{{closure}}
             at libstd/rt.rs:74
Traceback (most recent call last):
  File "./x.py", line 20, in <module>
    bootstrap.main()
  File "/home/glaubitz/rustc/rustc-1.28.0+dfsg1/src/bootstrap/bootstrap.py", line 826, in main
    bootstrap(help_triggered)
  File "/home/glaubitz/rustc/rustc-1.28.0+dfsg1/src/bootstrap/bootstrap.py", line 817, in bootstrap
    run(args, env=env, verbose=build.verbose)
  File "/home/glaubitz/rustc/rustc-1.28.0+dfsg1/src/bootstrap/bootstrap.py", line 149, in run
    raise RuntimeError(err)
RuntimeError: failed to run: /home/glaubitz/rustc/rustc-1.28.0+dfsg1/build/bootstrap/debug/bootstrap build --config debian/config.toml -vv --on-fail env
make[1]: *** [debian/rules:196: override_dh_auto_build-arch] Error 1
make[1]: Leaving directory '/home/glaubitz/rustc/rustc-1.28.0+dfsg1'

From the backtrace, it's not clear to me what the actual problem is. stage0 compiler is rust 1.27, cargo is 0.28. Both installed through Debian.

[glaubitz]

CC @jrtc27 @psumbera

[glaubitz]

Aha, the Rust compiler is generating code with unaligned access again:

glaubitz@kyoto:~$ ./stage2/bin/rustc hello.rs 
Bus error
glaubitz@kyoto:~$

[glaubitz]

Here's the backtrace:

(gdb) r hello.rs
Starting program: /home/glaubitz/stage2/bin/rustc hello.rs
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/sparc64-linux-gnu/libthread_db.so.1".

Program received signal SIGBUS, Bus error.
0xffff800100f37738 in rustc_resolve::Resolver::resolve_path () from /home/glaubitz/stage2/bin/../lib/../lib/librustc_resolve-ea53ebec52bf11a1.so
(gdb) bt
#0  0xffff800100f37738 in rustc_resolve::Resolver::resolve_path () from /home/glaubitz/stage2/bin/../lib/../lib/librustc_resolve-ea53ebec52bf11a1.so
#1  0xffff800100f2d2d4 in rustc_resolve::Resolver::smart_resolve_path_fragment () from /home/glaubitz/stage2/bin/../lib/../lib/librustc_resolve-ea53ebec52bf11a1.so
#2  0xffff800100f2ce70 in rustc_resolve::Resolver::smart_resolve_path_with_crate_lint () from /home/glaubitz/stage2/bin/../lib/../lib/librustc_resolve-ea53ebec52bf11a1.so
#3  0xffff800100f3b13c in rustc_resolve::Resolver::resolve_expr () from /home/glaubitz/stage2/bin/../lib/../lib/librustc_resolve-ea53ebec52bf11a1.so
#4  0xffff800100f3ac78 in rustc_resolve::Resolver::resolve_expr () from /home/glaubitz/stage2/bin/../lib/../lib/librustc_resolve-ea53ebec52bf11a1.so
#5  0xffff800100f176ec in <rustc_resolve::Resolver<'a, 'cl> as syntax::visit::Visitor<'tcx>>::visit_block () from /home/glaubitz/stage2/bin/../lib/../lib/librustc_resolve-ea53ebec52bf11a1.so
#6  0xffff800100f39cf0 in rustc_resolve::Resolver::resolve_labeled_block () from /home/glaubitz/stage2/bin/../lib/../lib/librustc_resolve-ea53ebec52bf11a1.so
#7  0xffff800100f3a564 in rustc_resolve::Resolver::resolve_expr () from /home/glaubitz/stage2/bin/../lib/../lib/librustc_resolve-ea53ebec52bf11a1.so
#8  0xffff800100f176ec in <rustc_resolve::Resolver<'a, 'cl> as syntax::visit::Visitor<'tcx>>::visit_block () from /home/glaubitz/stage2/bin/../lib/../lib/librustc_resolve-ea53ebec52bf11a1.so
#9  0xffff800100f19454 in <rustc_resolve::Resolver<'a, 'cl> as syntax::visit::Visitor<'tcx>>::visit_fn () from /home/glaubitz/stage2/bin/../lib/../lib/librustc_resolve-ea53ebec52bf11a1.so
#10 0xffff800100f5c900 in syntax::visit::walk_item () from /home/glaubitz/stage2/bin/../lib/../lib/librustc_resolve-ea53ebec52bf11a1.so
#11 0xffff800100f25084 in rustc_resolve::Resolver::resolve_item () from /home/glaubitz/stage2/bin/../lib/../lib/librustc_resolve-ea53ebec52bf11a1.so
#12 0xffff800100f20234 in rustc_resolve::Resolver::resolve_crate () from /home/glaubitz/stage2/bin/../lib/../lib/librustc_resolve-ea53ebec52bf11a1.so
#13 0xffff800100214138 in rustc::util::common::time () from /home/glaubitz/stage2/bin/../lib/librustc_driver-8c16f292143771bc.so
#14 0xffff800100200a68 in rustc_driver::driver::phase_2_configure_and_expand () from /home/glaubitz/stage2/bin/../lib/librustc_driver-8c16f292143771bc.so
#15 0xffff8001001fa128 in rustc_driver::driver::compile_input () from /home/glaubitz/stage2/bin/../lib/librustc_driver-8c16f292143771bc.so
#16 0xffff8001002cf8ec in rustc_driver::run_compiler_with_pool () from /home/glaubitz/stage2/bin/../lib/librustc_driver-8c16f292143771bc.so
#17 0xffff8001001e3c48 in <scoped_tls::ScopedKey<T>>::set () from /home/glaubitz/stage2/bin/../lib/librustc_driver-8c16f292143771bc.so
#18 0xffff800100284034 in syntax::with_globals () from /home/glaubitz/stage2/bin/../lib/librustc_driver-8c16f292143771bc.so
#19 0xffff8001001e1ca0 in <std::panic::AssertUnwindSafe<F> as core::ops::function::FnOnce<()>>::call_once () from /home/glaubitz/stage2/bin/../lib/librustc_driver-8c16f292143771bc.so
#20 0xffff8001002b580c in std::panicking::try::do_call () from /home/glaubitz/stage2/bin/../lib/librustc_driver-8c16f292143771bc.so
#21 0xffff80010057c55c in __rust_maybe_catch_panic () from /home/glaubitz/stage2/bin/../lib/libstd-fb04bd5ded883618.so
#22 0xffff8001002cbe90 in rustc_driver::run () from /home/glaubitz/stage2/bin/../lib/librustc_driver-8c16f292143771bc.so
#23 0xffff8001002dc4cc in rustc_driver::main () from /home/glaubitz/stage2/bin/../lib/librustc_driver-8c16f292143771bc.so
#24 0x0000010000000d98 in rustc_binary::main ()
#25 0x0000010000000d60 in std::rt::lang_start::{{closure}} ()
#26 0xffff800100534810 in std::sys_common::backtrace::__rust_begin_short_backtrace () from /home/glaubitz/stage2/bin/../lib/libstd-fb04bd5ded883618.so
#27 0xffff800100531b4c in std::panicking::try::do_call () from /home/glaubitz/stage2/bin/../lib/libstd-fb04bd5ded883618.so
#28 0xffff80010057c55c in __rust_maybe_catch_panic () from /home/glaubitz/stage2/bin/../lib/libstd-fb04bd5ded883618.so
#29 0xffff800100524038 in std::rt::lang_start_internal () from /home/glaubitz/stage2/bin/../lib/libstd-fb04bd5ded883618.so
#30 0x0000010000000de0 in main ()
(gdb)

[psumbera]

I think I now see the same on Solaris:

Building stage1 std artifacts (sparcv9-sun-solaris -> sparcv9-sun-solaris)
   Compiling cc v1.0.15
   Compiling core v0.0.0 (file:///scratch/userland-rust/components/rust/rustc/rustc-1.28.0-src/src/libcore)
   Compiling unwind v0.0.0 (file:///scratch/userland-rust/components/rust/rustc/rustc-1.28.0-src/src/libunwind)
   Compiling build_helper v0.1.0 (file:///scratch/userland-rust/components/rust/rustc/rustc-1.28.0-src/src/build_helper)
   Compiling compiler_builtins v0.0.0 (file:///scratch/userland-rust/components/rust/rustc/rustc-1.28.0-src/src/rustc/compiler_builtins_shim)
   Compiling alloc_jemalloc v0.0.0 (file:///scratch/userland-rust/components/rust/rustc/rustc-1.28.0-src/src/liballoc_jemalloc)
   Compiling std v0.0.0 (file:///scratch/userland-rust/components/rust/rustc/rustc-1.28.0-src/src/libstd)
error: Could not compile `core`.

Caused by:
  process didn't exit successfully: `/scratch/userland-rust/components/rust/rustc/build/sparcv9/build/bootstrap/debug/rustc --crate-name core libcore/lib.rs --error-format json --crate-type lib --emit=dep-info,link -C opt-level=2 -C metadata=15421603fe6aafcc -C extra-filename=-15421603fe6aafcc --out-dir /scratch/userland-rust/components/rust/rustc/build/sparcv9/build/sparcv9-sun-solaris/stage1-std/sparcv9-sun-solaris/release/deps --target sparcv9-sun-solaris -L dependency=/scratch/userland-rust/components/rust/rustc/build/sparcv9/build/sparcv9-sun-solaris/stage1-std/sparcv9-sun-solaris/release/deps -L dependency=/scratch/userland-rust/components/rust/rustc/build/sparcv9/build/sparcv9-sun-solaris/stage1-std/release/deps` (signal: 10, SIGBUS: access to undefined memory)
warning: build failed, waiting for other jobs to finish...
error: build failed
command did not execute successfully: "/usr/bin/cargo" "build" "--target" "sparcv9-sun-solaris" "-j" "4" "--release" "--features" "panic-unwind jemalloc backtrace" "--manifest-path" "/scratch/userland-rust/components/rust/rustc/rustc-1.28.0-src/src/libstd/Cargo.toml" "--message-format" "json"
expected success, got: exit code: 101
thread 'main' panicked at 'cargo must succeed', bootstrap/compile.rs:1091:9
note: Run with `RUST_BACKTRACE=1` for a backtrace.
failed to run: /scratch/userland-rust/components/rust/rustc/build/sparcv9/build/bootstrap/debug/bootstrap build
Build completed unsuccessfully in 1:10:13

And the relevant core file:

fffffe0105bc69b1 librustc_resolve-f7da6aed88d9027c.so`rustc_resolve::Resolver::resolve_path::ha5157224f22c831c+0xe80(0, fffffe0105bc73bb, 58ff9f240, 1, 2e7, 0)
fffffe0105bc6c51 librustc_resolve-f7da6aed88d9027c.so`rustc_resolve::Resolver::smart_resolve_path_fragment::h041fbab47f42dfc8.llvm.3454835783420331426+0x3c8(fffffe0105bc7748, fffffe0105bc7798 , 0, 0, 1, 58ff9f240)
fffffe0105bc7071 librustc_resolve-f7da6aed88d9027c.so`rustc_resolve::Resolver::smart_resolve_path_with_crate_lint::h7d3c2bcedb852c09.llvm.3454835783420331426+0x12c(fffffe0105bc7ab0,
fffffe0105bca988, ab, 0, c8bf10, c80000)
fffffe0105bc7181 librustc_resolve-f7da6aed88d9027c.so`rustc_resolve::Resolver::resolve_expr::hc44cbbdc46f8688b.llvm.3454835783420331426+0xed8(fffffe0105bc7be0, 1, 0, 58d379590, 1a,
7fec9a6f38eb0)
fffffe0105bc7461 librustc_resolve-f7da6aed88d9027c.so`syntax::visit::walk_expr::h39c023b86cb664d0+0x634(fffffe0105bca988, 58d379600, 0, 7fec99dcf2a40, 0, 0)
fffffe0105bc7541 librustc_resolve-f7da6aed88d9027c.so`rustc_resolve::Resolver::resolve_expr::hc44cbbdc46f8688b.llvm.3454835783420331426+0x1424(6, 6, 0, 58d379600, 6, fffffe0105bc7ae1)
fffffe0105bc7821 librustc_resolve-f7da6aed88d9027c.so`syntax::visit::walk_expr::h39c023b86cb664d0+0x624(fffffe0105bca988, 58d375140, 0, 10, 20000, 0)
fffffe0105bc7901 librustc_resolve-f7da6aed88d9027c.so`rustc_resolve::Resolver::resolve_expr::hc44cbbdc46f8688b.llvm.3454835783420331426+0x1424(6, 6, 0, 58d375140, 6, 0)
fffffe0105bc7be1 librustc_resolve-f7da6aed88d9027c.so`_$LT$rustc_resolve..Resolver$LT$$u27$a$GT$$u20$as$u20$syntax..visit..Visitor$LT$$u27$tcx$GT$$GT$::visit_block::hdde10983d1278566+0x52c(
fffffe0105bca988, 1, 2, fffffe0105bc8500, 600000000, fffffe0105bcab50)
fffffe0105bc7d21 librustc_resolve-f7da6aed88d9027c.so`_$LT$rustc_resolve..Resolver$LT$$u27$a$GT$$u20$as$u20$syntax..visit..Visitor$LT$$u27$tcx$GT$$GT$::visit_fn::h332d784b1e6a2bc6+0x2dc(
fffffe0105bca988, fffffe0105bc8718, 58d375b80, 1, fffffe0105bc85d8, 58d3793a0)
fffffe0105bc7e41 librustc_resolve-f7da6aed88d9027c.so`syntax::visit::walk_impl_item::h7b3d84fc2bc3659b+0x184(fffffe0105bca988, c80000, 8cb2, 0, 0, c8)
fffffe0105bc7f21 librustc_resolve-f7da6aed88d9027c.so`rustc_resolve::Resolver::resolve_item::h32c53a17a56ae871.llvm.3454835783420331426+0x5304(fffffe0105bcabb0, 0, fffffe0105bca988, c8,
fffffe0105bc8c10, fffffe0105bc8c14)
fffffe0105bc8591 librustc_resolve-f7da6aed88d9027c.so`syntax::visit::walk_item::ha6142223c2baa232+0x568(fffffe0105bca988, 58d34dc00, 8, 58d3778a0, ffffffffffffffff, 0)
fffffe0105bc8671 librustc_resolve-f7da6aed88d9027c.so`rustc_resolve::Resolver::resolve_item::h32c53a17a56ae871.llvm.3454835783420331426+0x31b0(2, 58d2d6110, fffffe0105bca988, 0, 8d2d6110, 0)
fffffe0105bc8ce1 librustc_resolve-f7da6aed88d9027c.so`rustc_resolve::Resolver::resolve_crate::h307f7daf20918a4a+0x64(5e, 190, 58ff1cc60, fffffe0105bca988, 58ff1cde8, 43)
fffffe0105bc90e1 librustc_driver-149ad7878e1d5dd3.so`rustc::util::common::time::h3329e251b97df331+0x68(fffffe0105bcdd50, 7fec9a75775b9, f, fffffe0105bca988, fffffe0105bca758, 7fec9a78b4000)
fffffe0105bc91a1 librustc_driver-149ad7878e1d5dd3.so`rustc_driver::driver::phase_2_configure_and_expand::h6a1ae09f98791f8d+0x1bdc(1110, fffffe0105bca738, 1, 80, 58fd499f0, fffffe0105bcdcb0)
fffffe0105bcb001 librustc_driver-149ad7878e1d5dd3.so`rustc_driver::driver::compile_input::h7dcb68da1f23b1e3+0x878(fffffe0105bcdd50, fffffe0105bcdcb0, 4, fffffe0105bcd948, fffffe0105bcbf20,
fffffe0105bcba08)
fffffe0105bcd311 librustc_driver-149ad7878e1d5dd3.so`rustc_driver::run_compiler_with_pool::hf1ceed5ff951d98b+0x1ca4(fffffe0105bcf648, fffffe0105bcf0c8, fffffe0105bd04e0, 0, 8, 7fec9a78f5a60)
fffffe0105bcee61 librustc_driver-149ad7878e1d5dd3.so`_$LT$scoped_tls..ScopedKey$LT$T$GT$$GT$::set::h24a64c5b7b9affe0+0x4bc(fffffe0105bd20e0, 1, fffffe0105bd04e0, fffffe0105bd0498, 1f, 1)
fffffe0105bd0231 librustc_driver-149ad7878e1d5dd3.so`syntax::with_globals::h6f9eaf6685650d0b+0x74(fffffe0105bd20e0, fffffe0105bd0ae8, d68, 7fec9a78b4000, 0, 7fec9a78f5a60)
fffffe0105bd04b1 librustc_driver-149ad7878e1d5dd3.so`_$LT$std..panic..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$::call_once::h6316249408c1c0c9+0x118( 58d24e330, fffffe0105bd20e0, 23, 7fec9a78f5a60, 7fec9a78b4000, 7fec9a7f44578)
fffffe0105bd2ce1 librustc_driver-149ad7878e1d5dd3.so`std::panicking::try::do_call::h10528e570b35fd77.llvm.2680291196597576240+4(fffffe0105bd38f0, 7fec9a78b7238, f, 7fec9a7753cb4, e, 58d24b420)fffffe0105bd2d91 libstd-2f27b31b5fc35d59.so`__rust_maybe_catch_panic+0x14(7fec9a776cc7c, fffffe0105bd38f0, fffffe0105bd38a8, fffffe0105bd3718, 7fec9a7238000, 0)
fffffe0105bd2e51 librustc_driver-149ad7878e1d5dd3.so`rustc_driver::run::hfe1c835c6c1cd71a+0xcf4(3, bb8, e, 0, 0, 7fec9a78b4000)
fffffe0105bd3131 librustc_driver-149ad7878e1d5dd3.so`rustc_driver::main::h5e7673d41020bdee+0xc(7fec9a78b4000, 0, 2, 1081, 20, 1)
fffffe0105bd31e1 rustc_binary::main::ha2e94622e090af62+0xc(0, 0, 7fec9a6f2eb80, 7fec99dcf2a40, 1, 1)
fffffe0105bd3291 std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::h51da7e41ef2cd75d+8(1000014b8, 0, 7fec9a6ddf240, 7fec99dcf2a40, 7fec9a6f2eb80, 0)
fffffe0105bd3341 libstd-2f27b31b5fc35d59.so`std::sys_common::backtrace::__rust_begin_short_backtrace::h00aa9d27d1494379+8(fffffe0105bd3f38, 100001484, 7fec9a70ca8dc, 7fec9a71060bc,
7fec9a7f328f0, 7fec9a7f44578)
fffffe0105bd33f1 libstd-2f27b31b5fc35d59.so`std::panicking::try::do_call::h83b80c66b071754d.llvm.3392808167829329524+0xc(fffffe0105bd3e38, fffffe0105bd3e10, 1, 7fec9a70ca8dc, 0, 0)
fffffe0105bd34a1 libstd-2f27b31b5fc35d59.so`__rust_maybe_catch_panic+0x14(7fec9a70fdb9c, fffffe0105bd3e38, fffffe0105bd3e70, fffffe0105bd3e78, 7fec9a7238000, 0)
fffffe0105bd3561 libstd-2f27b31b5fc35d59.so`std::rt::lang_start_internal::h6980b458b9343027+0x138(fffffe0105bd3e50, fffffe0105bd3e78, 23, fffffe0105bd3ff8, 1, 7fec9a7238000)
fffffe0105bd3681 main+0x38(30, fffffe0105bd3ff8, 100102000, 1000014b8, 0, 0)
fffffe0105bd3741 _start+0x64(0, 0, 0, 0, 0, 0)

[glaubitz]

What bothers me is that I am not getting any line numbers.

[glaubitz]

It's #45679 again.

@mkarcher @nikomatsakis

@psumbera This workaround fixes it: d4745f8

[nikomatsakis]

Blast from the past. I've nominated this for discussion. I can't quite tell what the current status is -- I know @arielb1 wanted to land some changes to make derive work properly in the presence of packed, did that ever happen? If not, maybe we should land the workaround for the time being?

[Mark-Simulacrum]

Derive should mostly work for packed, I think. We should be emitting lints if it didn't work...

[arielb1]

@nikomatsakis

First, #[derive] should be generating the correct code.
Second, Span does not use derive anyway:

rust/src/libsyntax_pos/span_encoding.rs

Lines 24 to 30 in 0aa8d03

	/// A compressed span.
	/// Contains either fields of `SpanData` inline if they are small, or index into span interner.
	/// The primary goal of `Span` is to be as small as possible and fit into other structures
	/// (that's why it uses `packed` as well). Decoding speed is the second priority.
	/// See `SpanData` for the info on span fields in decoded representation.
	#[repr(packed)]
	pub struct Span(u32);

[nikomatsakis]

Discussed at the @rust-lang/compiler meeting today. We're going to mark this as P-medium for now. Can anyone with access to a sparc validate whether @glaubitz's workaround does indeed resolve the problem:

This workaround fixes it: d4745f8

That would be very helpful, thanks!

[nikomatsakis]

To really track this down more effectively we would need some way to reproduce -- nobody has access to SPARC hardware.

[glaubitz]

Access to a SPARC porterbox can be provided to anyone interested in working on the problem.

…

On Aug 23, 2018, at 5:16 PM, Niko Matsakis ***@***.***> wrote: To really track this down more effectively we would need some way to reproduce -- nobody has access to SPARC hardware. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[glaubitz]

@nikomatsakis If you send me a private email with your public SSH key and your preferred username, I can create an account.

FWIW, @karcherm has already been debugging this issue on the SPARC box.

[arielb1]

I think I'll be helping with the debugging.

NOTE: I successfully reproduced everything locally. No SSH needed.

SSH key:
> ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIDOHSMpit8UwztZSSTvJktep7BdGwDa3ASUKPpC+NJL4 ariel@ariel-ubx

Preferred username: ariel
You can send the IP to my e-mail, ariel.byd@gmail.com

[psumbera]

Just for record. I use the workaround on Solaris sparc and it works for me (with Firefox build).

[karcherm]

I did not get that much results yet. I can reproduce the unaligned access when building natively on sparc64, compiling 1.28 with 1.27 (after applying the __divdi patch). It's already the stage1 compiler that produces the fault. The relevant assembler code (inside resolve_path) is

L1:
   0xffff800100f3583c <+3528>:  ldx  [ %fp + 0x627 ], %i0
   0xffff800100f35840 <+3532>:  or  %i0, 3, %i0
   0xffff800100f35844 <+3536>:  ldx  [ %fp + 0x63f ], %g2
L2:
   0xffff800100f35848 <+3540>:  ld  [ %i2 ], %i1
   0xffff800100f3584c <+3544>:  cmp  %i1, 0xc                        ! keywords::Extern.name()
   0xffff800100f35850 <+3548>:  be  0xffff800100f35864 <MYSELF+3568>
=> 0xffff800100f35854 <+3552>:  ld  [ %i0 ], %i0
   0xffff800100f35858 <+3556>:  cmp  %i1, 1                          ! keywords::CreateRoot.name()
   0xffff800100f3585c <+3560>:  bne  0xffff800100f359b0 <MYSELF+3900> ! return from inlined lint_if_path_starts_with_module

This is in the fist check of lint_if_path_starts_with_module, which has been inlined into resolve_path. The value of %i0 is used to initialize the %o2 in the call to buffer_lint_with_diagnostic later. Compiling without optimization seems to generate code without the unaligned access. Note that +3528 loads a correctly aligned pointer into %i0, +3532 intentionally misaligns it (no idea whether this is about setting tag bits or advancing to an unaligned member) and +3552 dereferences it.

Also interesting might be the assembly of the preceding code:

   0xffff800100f35668 <+3060>:  and  %i1, 3, %i0        ! begin inlined lint_if_path_starts_with_module
   0xffff800100f3566c <+3064>:  cmp  %i0, 1                        ! CrateLint::SimplePath
   0xffff800100f35670 <+3068>:  be  L1                                ! jumps to the crash
   0xffff800100f35674 <+3072>:  st  %i4, [ %fp + 0x69f ]
   0xffff800100f35678 <+3076>:  cmp  %i0, 2                        ! CrateLint::UsePath (case 1)
   0xffff800100f3567c <+3080>:  be  0xffff800100f35690 <MYSELF+3100>
   0xffff800100f35680 <+3084>:  ldx  [ %fp + 0x63f ], %g2
   0xffff800100f35684 <+3088>:  cmp  %i0, 3                        ! CrateLint::QPathTrait
   0xffff800100f35688 <+3092>:  bne  0xffff800100f359b0 <MYSELF+3900> ! jump if "No" to end of inlined fn
   0xffff800100f3568c <+3096>:  nop
   0xffff800100f35690 <+3100>:  ld  [ %fp + 0x71f ], %i0
   0xffff800100f35694 <+3104>:  stx  %i0, [ %fp + 0x65f ]
   0xffff800100f35698 <+3108>:  L2                                      ! jumps accross the crash (cases 2 & 3)
   0xffff800100f3569c <+3112>:  add  %fp, 0x69f, %i0

It seems that the generation of faulting code only happens if certain inlining decisions are made "the appropriate way". I tried to make a minimal example of this by hand and failed to get this assembly out of a smaller code file.

[estebank]

Out of curiosity, could #50960 (Bool vs c_uint llvm treatment being different for powerpc) be related to this?

[glaubitz]

@estebank Don't think so as #50960 turned out to be a bug in the powerpc backend of LLVM.

[arielb1]

I think I found it. This smells like an LLVM bug:

  %_587.sroa.4 = alloca [7 x i8], align 4
...
bb10.i:                                           ; preds = %bb7.i
  ; this is *definitely* unaligned, being of offset 3 into a 4-aligned alloca
  %_587.sroa.4.3.sroa_idx = getelementptr inbounds [7 x i8], [7 x i8]* %_587.sroa.4, i64 0, i64 3, !dbg !247022
  br label %bb13.i, !dbg !247023

...
bb13.i:                                           ; preds = %bb12.i, %bb11.i, %bb10.i
  %_14.sroa.0.0.in.in.i = phi i8* [ %_587.sroa.7.0.sroa_cast427, %bb12.i ], [ %_587.sroa.7.0.sroa_cast427, %bb11.i ], [ %_587.sroa.4.3.sroa_idx, %bb10.i ]
  %_14.sroa.6.0.i = phi i32 [ %_587.sroa.4.0._587.sroa.4.1.qpath_span.sroa.0.0.copyload.i, %bb12.i ], [ %_587.sroa.4.0._587.sroa.4.1.root_span.sroa.0.0.copyload.i, %bb11.i ], [ %5, %bb10.i ], !dbg !247028
  %_14.sroa.0.0.in.i = bitcast i8* %_14.sroa.0.0.in.in.i to i32*, !dbg !247030
  ; but somehow LLVM is emitting a load with align 4 here
  %_14.sroa.0.0.i = load i32, i32* %_14.sroa.0.0.in.i, align 4, !dbg !247028, !alias.scope !247025, !noalias !247026
  %77 = icmp eq i64 %61, 0, !dbg !247031
  br i1 %77, label %_ZN13rustc_resolve8Resolver31lint_if_path_starts_with_module17h8a282e5cd5cfe0bbE.exit, label %bb16.i, !dbg !247034

[arielb1]

Opened https://bugs.llvm.org/show_bug.cgi?id=38707 - @nagisa @eddyb and co: could you try to get it fixed?

[arielb1]

@glaubitz

Given that I reproduced the problem locally, I don't need the Sparc box anymore. Would be helpful if you could confirm that this is fixed after everything is done, though.

[glaubitz]

@arielb1 Yes, will do once there is a patch. And sorry for the late reply and thanks a lot for digging this up!

[glaubitz]

@arielb1 I can confirm that this patch fixes the issue: https://reviews.llvm.org/D51335

[arielb1]

The LLVM fix had been merged into rustc.

@glaubitz can you confirm that nightly works for you and close this issue?

[glaubitz]

@arielb1 Yes, I'll test it now.

[arielb1]

Is this fixed?

[glaubitz]

It has been fixed upstream: https://reviews.llvm.org/D51335

I can also confirm the patch works. I don't know whether it has been backported to Rust's own embedded LLVM copy though.

[arielb1]

The patch had been backported to nightly. Can you check that a recent nightly works on sparc? Or should I just close this issue?

[glaubitz]

Seems to be fixed in nightly. I could build cargo with nightly without any issues on sparc64. I'm now doing a full test build of rustc-nightly natively on sparc64 just to be sure.

FWIW, there are now sparc64 porterboxes available in the gcc compile farm, both running Solaris and Linux, which can be used for testing and development of Rust on sparc64:

https://cfarm.tetaneutral.net/machines/list/

Anyone who is an open source contributor can apply for an account.

[glaubitz]

@arielb1 I can confirm that nighly works correctly. You're free to close this bug.