mipsel targets: compilation fails with "Undefined temporary symbol $BB0_4"

[Mrmaxmeier]

Hi,

I hit a strange build failure in CI where rustc-demangle fails to build for mipsel-unknown-linux-gnu .

Here's a reduced reproducer:

// ⋊> rustc ./repro.rs --crate-type=lib --target mipsel-unknown-linux-gnu
// error: Undefined temporary symbol $BB0_4
//
// error: aborting due to previous error
pub fn func(s: &()) -> usize {
    #[allow(dead_code)]
    enum Error {
        VarA,
        VarB,
    }

    fn subfunc<'a>(_s: &'a ()) -> Result<&'a str, Error> {
        loop {}
    }
    match subfunc(s) {
        Ok(_d) => 1,
        Err(Error::VarA) | Err(Error::VarB) => 2,
    }
}

Meta

I'm using current nightly, but this is a regression from stable (1.67.1) to beta (1.68.0-beta.7).

rustc --version --verbose:

rustc 1.70.0-nightly (7820b62d2 2023-03-05)
binary: rustc
commit-hash: 7820b62d20bc548096d4632a3487987308cb4b5d
commit-date: 2023-03-05
host: x86_64-unknown-linux-gnu
release: 1.70.0-nightly
LLVM version: 15.0.7

cargo bisect-rustc points to d726c84 (in nightly-2022-11-01), but this feels like an LLVM bug.
I can't trigger it via --emit=llvm-ir and llc repro.ll -o repro.o -filetype=obj though. The LLVM version matches, but I'm probably not reproducing rustc's interactions with LLVM faithfully..

Sorry for the noise with obscure target architectures, but I'm reporting the issue here because I don't know how to reproduce it on LLVM's side 🙂

[workingjubilee]

Sorry for the noise with obscure target architectures

It's fine. We may not offer the best support for them due to technical and resource constraints, but we still want people to have the option to run Rust code on their OpenWRT router or their PlayStation or whatever.

[cnjn]

i hit the same problem. build rustc-demangle failed for mipsel-unknown-linux-gnu

[workingjubilee]

May be caused by a trigger for #113065

[taiki-e]

FYI, this can be worked around by enabling optimization.

$ cargo +1.67 build --target mipsel-unknown-linux-gnu
   Compiling repro v0.1.0 (...)
error: Undefined temporary symbol $BB0_4

error: could not compile `repro` due to previous error

$ cargo +1.67 build --target mipsel-unknown-linux-gnu --release
   Compiling repro v0.1.0 (...)
    Finished release [optimized] target(s) in 0.09s

$ RUSTFLAGS='-C opt-level=1' cargo +1.67 build --target mipsel-unknown-linux-gnu
   Compiling repro v0.1.0 (...)
    Finished dev [unoptimized + debuginfo] target(s) in 0.19s

The same workaround works for error from rustc-demangle when using build-std in the latest nightly. (taiki-e/rust-cross-toolchain@e820504, taiki-e/setup-cross-toolchain-action@1ca8c89, taiki-e/atomic-maybe-uninit@ec71c70, taiki-e/portable-atomic@d47811e)

[Fearyncess]

FYI, this can be worked around by enabling optimization.

Maybe its relocation is too far then that has been truncated?

[urosbericsyrmia]

This issue should be fixed by llvm/llvm-project#80799.
Initially, the cause of the issue and the solution are explained in llvm/llvm-project#80666, but more elegant solution is just to remove derived isBlockOnlyReachableByFallthrough for Mips architecture.

[DianQK]

@rustbot label llvm-fixed-upstream

[nikic]

Can someone confirm that this is fixed on nightly?

[Mrmaxmeier]

Yep. My initial reproducer fails with rustc 1.76.0 (07dca489a 2024-02-04) but compiles on 1.78.0-nightly (a84bb95a1 2024-02-13). 📈