Illegal instruction compiling `core` and `compiler_builtins` for target mips3 with ABI n64.

[sarchar]

Both modules core and compiler_builtins fail to compile with target mips3 and ABI set to n64. Note: they compile with ABI n32 no problem.

To reproduce, you could try checking out my project https://github.com/sarchar/libdragon-rs and changing the ABI from n32 to n64 in mips-nintendo64-none.json.

I expected to see this happen: core and compiler_builtins should compile

Instead, this happened: LLVM crashes with SIGILL (Illegal instruction) with opcode "ud2". I believe LLVM intentionally crashes when UB code is encountered.

Meta

rustc --version --verbose:

rustc 1.75.0-nightly (09df6108c 2023-10-17)
binary: rustc
commit-hash: 09df6108c84fdec400043d99d9ee232336fd5a9f
commit-date: 2023-10-17
host: x86_64-unknown-linux-gnu
release: 1.75.0-nightly
LLVM version: 17.0.2

[nikic]

I'd suggest trying nightly, which has LLVM 18. Maybe the issue has been fixed.

[sarchar]

I'll try it out at some point, but I've determined that pursuing abi=n64 is not worthwhile as the performance of the project would suffer.

[sarchar]

I have switched to abi=o32 and the latest nightly (2024-02-18) and am getting the same illegal instruction on core: (signal: 4, SIGILL: illegal instruction)

$ rustc --version --verbose
rustc 1.78.0-nightly (2bf78d12d 2024-02-18)
binary: rustc
commit-hash: 2bf78d12d33ae02d10010309a0d85dd04e7cff72
commit-date: 2024-02-18
host: x86_64-unknown-linux-gnu
release: 1.78.0-nightly
LLVM version: 18.1.0```

[ds84182]

Also hitting the same issue. clang 17 and 18 works, rust doesn't. https://godbolt.org/z/KhjTb3asj

GDB backtrace:

Thread 6 "opt cgu.0" received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7fffb55ff6c0 (LWP 2329)]
0x00007fffeed1468a in CC_MipsO32(unsigned int, llvm::MVT, llvm::MVT, llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&, llvm::ArrayRef<unsigned short>) () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM.so.18.1-rust-1.79.0-nightly
(gdb) bt
#0  0x00007fffeed1468a in CC_MipsO32(unsigned int, llvm::MVT, llvm::MVT, llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&, llvm::ArrayRef<unsigned short>) () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM.so.18.1-rust-1.79.0-nightly
#1  0x00007fffeed141c8 in CC_MipsO32_FP(unsigned int, llvm::MVT, llvm::MVT, llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&) () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM.so.18.1-rust-1.79.0-nightly
#2  0x00007fffeed0c7c8 in CC_Mips_FixedArg(unsigned int, llvm::MVT, llvm::MVT, llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&) () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM.so.18.1-rust-1.79.0-nightly
#3  0x00007fffed9ecc08 in llvm::CCState::AnalyzeFormalArguments(llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, bool (*)(unsigned int, llvm::MVT, llvm::MVT, llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&)) ()
   from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM.so.18.1-rust-1.79.0-nightly
#4  0x00007fffeed10af2 in llvm::MipsTargetLowering::LowerFormalArguments(llvm::SDValue, unsigned int, bool, llvm::SmallVectorImpl<llvm::ISD::InputArg> const&, llvm::SDLoc const&, llvm::SelectionDAG&, llvm::SmallVectorImpl<llvm::SDValue>&) const ()
   from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM.so.18.1-rust-1.79.0-nightly
#5  0x00007fffefbb4f2f in llvm::SelectionDAGISel::LowerArguments(llvm::Function const&) () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM.so.18.1-rust-1.79.0-nightly
#6  0x00007fffefb9b7c4 in llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM.so.18.1-rust-1.79.0-nightly
#7  0x00007fffefba3eaa in llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM.so.18.1-rust-1.79.0-nightly
#8  0x00007fffeecf855a in llvm::MipsDAGToDAGISel::runOnMachineFunction(llvm::MachineFunction&) () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM.so.18.1-rust-1.79.0-nightly
#9  0x00007fffefb7ed15 in llvm::FPPassManager::runOnFunction(llvm::Function&) () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM.so.18.1-rust-1.79.0-nightly
#10 0x00007fffefb7e185 in llvm::FPPassManager::runOnModule(llvm::Module&) () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM.so.18.1-rust-1.79.0-nightly
#11 0x00007ffff0079760 in llvm::legacy::PassManagerImpl::run(llvm::Module&) () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/../lib/libLLVM.so.18.1-rust-1.79.0-nightly
#12 0x00007ffff6b3bb10 in LLVMRustWriteOutputFile () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-21abefbb4f7cccbb.so
#13 0x00007ffff6b3b728 in rustc_codegen_llvm[dea4b532a132fe1]::back::write::write_output_file () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-21abefbb4f7cccbb.so
#14 0x00007ffff6b39461 in rustc_codegen_llvm[dea4b532a132fe1]::back::write::codegen () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-21abefbb4f7cccbb.so
#15 0x00007ffff6b39145 in rustc_codegen_ssa[e08ec6553c5b268c]::back::write::finish_intra_module_work::<rustc_codegen_llvm[dea4b532a132fe1]::LlvmCodegenBackend> () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-21abefbb4f7cccbb.so
#16 0x00007ffff6b36fca in std[28e079ecff9295a0]::sys_common::backtrace::__rust_begin_short_backtrace::<<rustc_codegen_llvm[dea4b532a132fe1]::LlvmCodegenBackend as rustc_codegen_ssa[e08ec6553c5b268c]::traits::backend::ExtraBackendMethods>::spawn_named_thread<rustc_codegen_ssa[e08ec6553c5b268c]::back::write::spawn_work<rustc_codegen_llvm[dea4b532a132fe1]::LlvmCodegenBackend>::{closure#0}, ()>::{closure#0}, ()> () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-21abefbb4f7cccbb.so
#17 0x00007ffff6b36aa7 in <<std[28e079ecff9295a0]::thread::Builder>::spawn_unchecked_<<rustc_codegen_llvm[dea4b532a132fe1]::LlvmCodegenBackend as rustc_codegen_ssa[e08ec6553c5b268c]::traits::backend::ExtraBackendMethods>::spawn_named_thread<rustc_codegen_ssa[e08ec6553c5b268c]::back::write::spawn_work<rustc_codegen_llvm[dea4b532a132fe1]::LlvmCodegenBackend>::{closure#0}, ()>::{closure#0}, ()>::{closure#2} as core[b4e8c3011bb447ec]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0} () from /home/ds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/../lib/librustc_driver-21abefbb4f7cccbb.so 
#18 0x00007ffff1999a1b in alloc::boxed::{impl#48}::call_once<(), dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:2018
#19 alloc::boxed::{impl#48}::call_once<(), alloc::boxed::Box<dyn core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>, alloc::alloc::Global> () at library/alloc/src/boxed.rs:2018
#20 std::sys::pal::unix::thread::{impl#2}::new::thread_start () at library/std/src/sys/pal/unix/thread.rs:108
#21 0x00007ffff177b45c in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:444
#22 0x00007ffff17fbbbc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

[ds84182]

Looks like it affects any fn that accepts an i64 or wider as an argument. I think its an issue with Rust's LLVM patches.

Inserting the IR generated by rustc (https://godbolt.org/z/nvccKhGdf) into llc (https://godbolt.org/z/PnfToc7bY) does not crash.

[nikic]

@ds84182 It does if you enable assertions: https://godbolt.org/z/v4185GfY4

[ds84182]

@nikic darn, ok. Going to use an external LLVM build with assertions disabled in the meantime. Also the generated code for passing 64-bit ints might be wrong, but it only matters when linking with GCC compiled code.

[rakicaleksandar1999]

The back-end doesn't support using the 64-bit integers (i64) when using an ABI O32 on a 64-bit mips3 processor. The ABI O32 was initially intended for 32-bit processors, and the ABI N32 was later added to support the 64-bit numbers on the 64-bit processors. For now, the ABI N32 can be used when using the 64-bit integers on a 64-bit processor. The use of the 64-bit integers with the ABI O32 on the 64-bit processors may be temporarily prohibited until the support is complete. The support for the 64-bit integers with the ABI O32 on the 64-bit processors can be added in a similar way as the existing support for the type f64.