riscv64: rustc-LLVM ERROR: failed to perform tail call elimination on a call site marked musttail

[yuzibo]

When I was trying to deploy [external CI](#t-infra > We're eager to provide the community with RISC-V CI infrastr) for riscv64, I got this case failed with ./x test --stage 2

failures:

---- [ui] tests/ui/explicit-tail-calls/become-indirect-return.rs stdout ----

error: test compilation failed although it shouldn't!
status: exit status: 101
command: env -u RUSTC_LOG_COLOR RUSTC_ICE="0" RUST_BACKTRACE="short" "/workspace/rust/build/riscv64gc-unknown-linux-gnu/stage2/bin/rustc" "/workspace/rust/tests/ui/explicit-tail-calls/become-indirect-return.rs" "-Zthreads=1" "-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX" "-Ztranslate-remapped-path-to-local-path=no" "-Z" "ignore-directory-in-diagnostics-source-blocks=/root/.cargo" "-Z" "ignore-directory-in-diagnostics-source-blocks=/workspace/rust/vendor" "--sysroot" "/workspace/rust/build/riscv64gc-unknown-linux-gnu/stage2" "--target=riscv64gc-unknown-linux-gnu" "--check-cfg" "cfg(test,FALSE)" "-O" "--error-format" "json" "--json" "future-incompat" "-Ccodegen-units=1" "-Zui-testing" "-Zdeduplicate-diagnostics=no" "-Zwrite-long-types-to-disk=no" "-Cstrip=debuginfo" "-C" "prefer-dynamic" "-o" "/workspace/rust/build/riscv64gc-unknown-linux-gnu/test/ui/explicit-tail-calls/become-indirect-return/a" "-A" "internal_features" "-A" "unused_parens" "-A" "unused_braces" "-Crpath" "-Cdebuginfo=0" "-Lnative=/workspace/rust/build/riscv64gc-unknown-linux-gnu/native/rust-test-helpers"
stdout: none
--- stderr -------------------------------
rustc-LLVM ERROR: failed to perform tail call elimination on a call site marked musttail
------------------------------------------

---- [ui] tests/ui/explicit-tail-calls/become-indirect-return.rs stdout end ----

failures:
    [ui] tests/ui/explicit-tail-calls/become-indirect-return.rs

test result: FAILED. 8 passed; 1 failed; 20014 ignored; 0 measured; 0 filtered out; finished in 2.43s

Some tests failed in compiletest suite=ui mode=ui host=riscv64gc-unknown-linux-gnu target=riscv64gc-unknown-linux-gnu
help: ignored 19611 up-to-date tests; use `--force-rerun` to prevent this

May this is hard to fix it, but please let me open one issue to better track this.

Meta

rustc --version --verbose:

rustc 1.93.0-dev

[folkertdev]

There are still some issues with musttail for riscv, see e.g. llvm/llvm-project#157814.

So I think the test should be marked as //@ ignore-riscv64, maybe with a link to this issue or the LLVM issue.

godbolt to see if it works now: https://godbolt.org/z/7af8Go3vq

[InvalidPathException]

@rustbot claim

are there any other platforms known to be problematic with musttail?

[folkertdev]

Note that the fix here is almost certainly in LLVM, this is not a rust bug.

are there any other platforms known to be problematic with musttail?

Probably, for less common target architectures, LLVM just doesn't test these attributes very thoroughly. So it might be useful to add a version of the failing test https://github.com/rust-lang/rust/blob/master/tests/ui/explicit-tail-calls/become-indirect-return.rs that uses minicore to check a bunch of architectures.

This file

rust/tests/ui/abi/compatibility.rs

Line 4 in 86b95eb

//@ revisions: i686

has a bunch of revisions that might be of interest there.

[InvalidPathException]

Note that the fix here is almost certainly in LLVM, this is not a rust bug.

Thank you. A quick dive into LLVM issues - seems like we need to at least ignore the below for similar tests related to musttail, and they have been around for very long.

//@ ignore-riscv64 (https://github.com/llvm/llvm-project/issues/157814)
//@ ignore-mips (https://github.com/llvm/llvm-project/issues/57795)
//@ ignore-mips64
//@ ignore-powerpc (https://github.com/llvm/llvm-project/issues/63214)
//@ ignore-powerpc64
//@ ignore-aix
//@ ignore-thumb (https://github.com/llvm/llvm-project/issues/73167)

The problematic test here is marked as run-pass because the PR added it addressed a miscompilation that cause crash at run-time.

But it is not the only problematic test, for example: https://godbolt.org/z/bGf9zb5eK (rust/tests/ui/explicit-tail-calls/callee_is_track_caller_polymorphic.rs. As a side-note, is it going through GCC problematic on its own? We have no explicit-tail-call support for GCC yet?)

Anything that involves //@ run-pass or //@ build-pass has high likelihood of causing trouble on the platforms. We could for now just blankly ignore these platforms, is there a better way to handle this?

[folkertdev]

You can format that slightly differently to get a quick overview of the current status:

• ignore-riscv64
  • [clang] RISC-V: failed to perform tail call elimination on a call site marked musttail llvm/llvm-project#157814
• ignore-mips
  • clang15/mips backend: failed to perform tail call elimination on a call site marked musttail llvm/llvm-project#57795
  • [[clang::musttail]] triggers backend crash in llc on MIPS llvm/llvm-project#161193
  • [MIPS][ISel] Fix musttail llvm/llvm-project#161860
• ignore-mips64
• ignore-powerpc
  • [PowerPC] fatal error: error in backend: failed to perform tail call elimination on a call site marked musttail llvm/llvm-project#63214
  • [PowerPC] [LLD][Compiler] support tail call across modules for ELFv2 llvm/llvm-project#98859
• ignore-powerpc64
• ignore-aix
• ignore-thumb
  • LLVM backend crashes on armv7 thumb when musttail with more than 5 parameters llvm/llvm-project#73167

As a side-note, is it going through GCC problematic on its own? We have no explicit-tail-call support for GCC yet?

//@ ignore-backends: gcc ignores the GCC backend, because it currently does not know how to lower become.

is there a better way to handle this?

So beside riscv, most of the targets in that list are very niche and see little usage. So I don't think every tail call test should ignore all of them. If you go check, many tests would fail on those plaforms, because we don't run CI for them.

So probably having one basic tests, with all of those different target combinations, is best. That way it is easy to check if issues for a target were resolved, e.g. when we update LLVM.