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.