can not compile in release mode in raspberry pi zero

[sk-Prime]

For testing purpose i created simplest hello world program using, cargo new hello_world, in debug mode cargo build it is compiling without any issue. however in release mode cargo build --release it can not compile the program.

fn main() {
    println!("Hello, world!");
}

rustc main.rs can compile the program too but rustc -O main.rs produces similar error.
I expected to see this happen: compile

Meta

rustc --version --verbose:

rustc 1.41.0 (5e1a79984 2020-01-27)
binary: rustc
commit-hash: 5e1a799842ba6ed4a57e91f7ab9435947482f7d8
commit-date: 2020-01-27
host: arm-unknown-linux-gnueabihf
release: 1.41.0
LLVM version: 9.0

Error

pi@raspberrypi:~/rust/hello_world $ cargo build --release
   Compiling hello_world v0.1.0 (/home/pi/rust/hello_world)
error: could not compile `hello_world`.

Caused by:
  process didn't exit successfully: `rustc --edition=2018 --crate-name hello_world src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C opt-level=3 -C metadata=40ad385247a6820a -C extra-filename=-40ad385247a6820a --out-dir /home/pi/rust/hello_world/target/release/deps -L dependency=/home/pi/rust/hello_world/target/release/deps` (signal: 11, SIGSEGV: invalid memory reference)

[memoryruins]

Does it compile if codegen-units is set to 1? Previously this helped in #62896

[sk-Prime]

yes it is now compiling successfully in release mode.

[betseg]

nice.

[repnop]

Ran into this issue attempting to compile https://github.com/ClementTsang/bottom on my Pi Zero W, segfaults even with -C codegen-units=1 when building the final binary after a long time w/ (signal: 11, SIGSEGV: invalid memory reference)

[Aaron1011]

I was able to reproduce this on my amd64 Arch laptop using https://github.com/fkrull/docker-qemu-user-static, and running rustup toolchain add stable-arm-unknown-linux-gnueabihf inside the Docker container.

Unfortunately, the only information I could get from the core file was this:

(gdb) bt
#0  0xfb18b3e8 in void std::__insertion_sort<__gnu_cxx::__normal_iterator<std::pair<unsigned long long, llvm::Function*>*, std::vector<std::pair<unsigned long long, llvm::Function*>, std::allocator<std::pair<unsigned long long, llvm::Function*> > > >, __gnu_cxx::__ops::_Iter_comp_iter<llvm::less_first> >(__gnu_cxx::__normal_iterator<std::pair<unsigned long long, llvm::Function*>*, std::vector<std::pair<unsigned long long, llvm::Function*>, std::allocator<std::pair<unsigned long long, llvm::Function*> > > >, __gnu_cxx::__normal_iterator<std::pair<unsigned long long, llvm::Function*>*, std::vector<std::pair<unsigned long long, llvm::Function*>, std::allocator<std::pair<unsigned long long, llvm::Function*> > > >, __gnu_cxx::__ops::_Iter_comp_iter<llvm::less_first>) () from /root/.rustup/toolchains/stable-arm-unknown-linux-gnueabihf/bin/../lib/librustc_driver-b281b647ba3a1a96.so
#1  0xf454b000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

I'm not 100% certain that that frame is correct - however, it makes sense, since the crash is occurring when LLVM is invoked.

[pnkfelix]

This is presumably a regression, right? It seems like a program this simple should have compiled successfully at some point?

Tagging with E-needs-bisect based on that assumption.

[pnkfelix]

triage as P-high, and also leave it nominated in hopes of discussing at T-compiler meeting.

[pnkfelix]

@rustbot ping icebreakers-llvm

[rustbot]

Hey LLVM ICE-breakers! This bug has been identified as a good
"LLVM ICE-breaking candidate". In case it's useful, here are some
instructions for tackling these sorts of bugs. Maybe take a look?
Thanks! <3

cc @comex @DutchGhost @hanna-kruppe @hdhoang @heyrutvik @JOE1994 @jryans @mmilenko @nagisa @nikic @Noah-Kennedy @SiavoshZarrasvand @spastorino @vertexclique @vgxbj

[spastorino]

After revisiting this, leaving as P-high and removing nomination.

[lopsided98]

This bug on armv7l (#62896) was fixed by upgrading the CI builds to use GCC 8 in e66a628. This change only applied to armv7l, so it seems like doing the same for armv6 would potentially fix this bug.

[spastorino]

@sk-Prime can you try this out and if it works provide a PR?, thanks!.

[sk-Prime]

My system is fully updated with gcc 8.3.0 (so doesn't work on armv6)
fn main() {let x=100; println!("{}",x);} compiling with rustc -O produces segmentation fault.

[lopsided98]

How did you install your Rust compiler? If you got it through rustup then it was not built with GCC 8.

[sk-Prime]

@lopsided98 yes, using rustup, the standard method.

[lopsided98]

See #70414