some tier 2 rustc 1.81 hosts cannot bootstrap stable 1.82 #129268
Labels
C-bug
Category: This is a bug.
I-crash
Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
O-riscv
Target: RISC-V architecture
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
rustbot
added
the
needs-triage
|
This looks like a duplicate of #117022 which concluded this is a kernel bug. |
saethlin
added
I-crash
|
Is there a list of kernel versions where rust can be successfully compiled? |
|
No. Why do you ask? |
Because you said it is a kernel bug. There should be a list of kernels where this bug does not exist (or maybe a kernel version after which the bug started appearing). In my first post, I tried building it on Banana Pi-F3 RISC-V SBC where it gave the error. The output of Now I changed the computing machine to visionfive 2 which is running debian. The output of This time (while building on visionfive 2) I received the following error: Basically, the context is that I own a RISC-V cloud computing platform with various RISC-V machines of multiple vendors and I am trying to set up fortnight CI builds of rustc (along with other programs) which would periodically build the master branch and archive the binary in cloud storage which is publicly accessible. The last build where I got the error (console output) is: https://dash.cloud-v.co/job/cloud-v-builds-folder/job/rust-riscv-build/24/console The builds are accessible here: https://dash.cloud-v.co/job/cloud-v-builds-folder/job/rust-riscv-build/ |
|
This looks more like a llvm error than a kernel error. While reading the documentation for building from the source at this, it says we either require clang++ or g++. Is there a way to force the build process to use gnu compilers instead of llvm compilers? |
If you read through the issue that I linked there is quite a bit of discussion including a comment which links to a Linux bug report and mentions a kernel version that should contain the fix. But of course you are on a distro, which may have backported the fix to any version. So even if we maintained a list of Linux bugs encountered by Rust users (which would be an unreasonable maintenance burden for the Rust project) it wouldn't necessarily be what you want.
Indeed, the new backtrace you have posted is completely different. Actually this looks like just a Rust compiler issue; it seems like the beta compiler is trying to compile some f16 code, and it shouldn't be. I cannot reproduce this error on x86_64, so I wonder if this is somehow riscv-specific for example because our |
|
@saethlin Thanks for considering it. BTW, I can give access to the RISC-V 64 instance to you or set up a RISC-V 64 CI in Jenkins for this repository if you want. |
workingjubilee
added
T-compiler
|
Based on #129268 (comment) it's not clear to me that there is no bug here. Also however it seems the target maintainers are not responding? Trying again: @kito-cheng I suppose I can send them an email... |
saethlin
removed
the
needs-triage
I'm maintainer for the LLVM RISC-V backend, but I've never done anything with Rust. |
|
There was a change to that part of abi.rs 5 months ago to add f16. 99e6a28 |
|
@topperc Ah, sorry to bother you! It's useful to know the relevant LLVM contact, but we should really specify that poking you is for LLVM problems specifically. Hmmm, yes, but it's odd that would fail while building the nightly... I suppose we are cross-building this target, though, so maybe it's just not surprising if someone can't bootstrap the compiler on RISCV... re: f16 @nicholasbishop and @tgross35 did you encounter any bootstrap-related problems? |
Not in a long time - the basic Lines 96 to 117 in 5384697
|
|
@alitariq4589 Does the issue described in #129268 (comment) still occur? I think it should have been fixed by the stage0 bump to 1.82 in #129941. |
I had also seen this issue previously, where FP16 type wasn't supported on riscv64. However, I have retried compiling the Rust compiler again on a VisionFive2 and on a Milk-V Jupiter board, and now there is no issue with the FP16 type. Note that I did have to patch the Linux kernel (Ubuntu 23.10, kernel version 6.1.15) on the Milk-V Jupiter board to fix the issue with #117022. |
kxxt
added a commit
to kxxt/archriscv-packages
that referenced
this issue
Oct 20, 2024
Musl Patch ========== riscv64gc-unknown-linux-musl gets promoted to tier 2 and `crt_static_default` is updated to false in rust-lang/rust#122049, which triggers rust-lang/rust#82521 (comment) when building stage2 library artifacts (riscv64gc-unknown-linux-gnu -> riscv64gc-unknown-linux-musl). I patched it to re-enable `crt_static_default` for `riscv64gc-unknown-linux-musl` to fix the build and align with the behavior on x86 Arch Linux, where `rust-musl` defaults to statically link musl. Wasm compiler_builtins bug ========================== Wasm compiler_builtins rlib from built `rust-wasm` package includes objects for host architecture(riscv64 in our case, and x86_64 for x86 Arch Linux). This is not reproducible for toolchains installed via rustup so I have reported it to Arch Linux: https://gitlab.archlinux.org/archlinux/packaging/packages/rust/-/issues/3 Complications when building 1.82.0 ================================== rust-lang/rust#125016 landed in 1.82.0, which breaks building rust 1.82.0 using our packaged rust 1.81.0. Compiling the new compiler_builtins component requires a rustc compiler that includes rust-lang/rust@99e6a28 but unfortunately 1.81.0 does not, leading to the following ICE: https://archriscv.felixc.at/.status/log.htm?url=logs/rust/rust-1:1.82.0-1.log internal compiler error: compiler/rustc_codegen_llvm/src/abi.rs:126:22: unsupported float: Reg { kind: Float, size: Size(2 bytes) } This is mitigated upstream by bumping stage0 to 1.82: rust-lang/rust#129268 (comment) So we need to first build 1.82.0 rustc once without the f16/f128 handling part in compiler_builtins, to get a compiler that is capable of handling f16/f128. And then we can use this compiler to compile compiler_builtins with f16/f128 handling. It's not easy to do so in one patch. The most easy way is to build and package rust 1.82.0 twice. This PR covers the first part and disable-f16-f128.diff will be removed in the second part.
kxxt
added a commit
to kxxt/archriscv-packages
that referenced
this issue
Oct 20, 2024
Musl Patch ========== riscv64gc-unknown-linux-musl gets promoted to tier 2 and `crt_static_default` is updated to false in rust-lang/rust#122049, which triggers rust-lang/rust#82521 (comment) when building stage2 library artifacts (riscv64gc-unknown-linux-gnu -> riscv64gc-unknown-linux-musl). I patched it to re-enable `crt_static_default` for `riscv64gc-unknown-linux-musl` to fix the build and align with the behavior on x86 Arch Linux, where `rust-musl` defaults to statically link musl. Wasm compiler_builtins bug ========================== Wasm compiler_builtins rlib from built `rust-wasm` package includes objects for host architecture(riscv64 in our case, and x86_64 for x86 Arch Linux). This is not reproducible for toolchains installed via rustup so I have reported it to Arch Linux: https://gitlab.archlinux.org/archlinux/packaging/packages/rust/-/issues/3 Complications when building 1.82.0 ================================== rust-lang/rust#125016 landed in 1.82.0, which breaks building rust 1.82.0 using our packaged rust 1.81.0. Compiling the new compiler_builtins component requires a rustc compiler that includes rust-lang/rust@99e6a28 but unfortunately 1.81.0 does not, leading to the following ICE: https://archriscv.felixc.at/.status/log.htm?url=logs/rust/rust-1:1.82.0-1.log internal compiler error: compiler/rustc_codegen_llvm/src/abi.rs:126:22: unsupported float: Reg { kind: Float, size: Size(2 bytes) } This is mitigated upstream by bumping stage0 to 1.82: rust-lang/rust#129268 (comment) So we need to first build 1.82.0 rustc once without the f16/f128 handling part in compiler_builtins, to get a compiler that is capable of handling f16/f128. And then we can use this compiler to compile compiler_builtins with f16/f128 handling. It's not easy to do so in one patch. The most easy way is to build and package rust 1.82.0 twice. This PR covers the first part and disable-f16-f128.diff will be removed in the second part.
felixonmars
pushed a commit
to felixonmars/archriscv-packages
that referenced
this issue
Oct 20, 2024
Musl Patch ========== riscv64gc-unknown-linux-musl gets promoted to tier 2 and `crt_static_default` is updated to false in rust-lang/rust#122049, which triggers rust-lang/rust#82521 (comment) when building stage2 library artifacts (riscv64gc-unknown-linux-gnu -> riscv64gc-unknown-linux-musl). I patched it to re-enable `crt_static_default` for `riscv64gc-unknown-linux-musl` to fix the build and align with the behavior on x86 Arch Linux, where `rust-musl` defaults to statically link musl. Wasm compiler_builtins bug ========================== Wasm compiler_builtins rlib from built `rust-wasm` package includes objects for host architecture(riscv64 in our case, and x86_64 for x86 Arch Linux). This is not reproducible for toolchains installed via rustup so I have reported it to Arch Linux: https://gitlab.archlinux.org/archlinux/packaging/packages/rust/-/issues/3 Complications when building 1.82.0 ================================== rust-lang/rust#125016 landed in 1.82.0, which breaks building rust 1.82.0 using our packaged rust 1.81.0. Compiling the new compiler_builtins component requires a rustc compiler that includes rust-lang/rust@99e6a28 but unfortunately 1.81.0 does not, leading to the following ICE: https://archriscv.felixc.at/.status/log.htm?url=logs/rust/rust-1:1.82.0-1.log internal compiler error: compiler/rustc_codegen_llvm/src/abi.rs:126:22: unsupported float: Reg { kind: Float, size: Size(2 bytes) } This is mitigated upstream by bumping stage0 to 1.82: rust-lang/rust#129268 (comment) So we need to first build 1.82.0 rustc once without the f16/f128 handling part in compiler_builtins, to get a compiler that is capable of handling f16/f128. And then we can use this compiler to compile compiler_builtins with f16/f128 handling. It's not easy to do so in one patch. The most easy way is to build and package rust 1.82.0 twice. This PR covers the first part and disable-f16-f128.diff will be removed in the second part.
|
it seems we are now running into this issue in Debian when building 1.82 with 1.81 on riscv64: this is with a previously built 1.81 that is using LLVM 18, with the 1.82 build using LLVM 19 (both LLVM versions as packaged in Debian, not using the bundled LLVM from upstream) any pointers on how to avoid it (other than possibly re-bootstrapping using a pre-compiled 1.82 stage0)? |
|
@Fabian-Gruenbichler is it possible to cherry pick 99e6a28 to 1.81 and rebuild that version? For the others: I am pretty sure that the issue in #129268 (comment) has to be caused by bootstrapping with something that does not include the above commit, i.e. < 1.82. The issue in the top post is different though, @alitariq4589 does that still reproduce for you! |
|
Another solution might be to enable compiler-builtins Since version 0.1.115, |
19 tasks
|
Our distributed host toolchain for riscv64 is cross-built from an x86_64 host. |
workingjubilee
changed the title
|
It seems if you wish to bootstrap using only riscv64, you will have to either backport the fix or go through the nightly releases. |
@Fabian-Gruenbichler This could be done by first building 1.82 with no-f16-f128 feature on compiler_builtins and then building it normally. I am doing it this way for Arch Linux RISC-V: |
|
thanks for the pointers! |
|
Got this error on loongarch64 too. |
workingjubilee
changed the title
14 tasks
skeuchel
added a commit
to skeuchel/nixpkgs
that referenced
this issue
Oct 26, 2024
Change the bootstrap on all platforms to use a version of the upstream binary that is equal to the version that is being built, instead of a binary of one version prior. This is necessary for the 1.82.0 release because on some platforms (rust-lang/rust#129268) the 1.81.0 binary can not build the 1.82.0 source. Furthermore, upstream reported that their development process (now) usually involves building a release compiler with itself and that "the Rust compiler must be able to build itself".
|
Update! I am using I tried installing transformers from pip on RISC-V Milk-V Jupiter running Ubuntu 23.10 and kernel version 6.1.15. I got the following Rust error. The error comes in the pip subprocess but is identical to my original problem regarding Rust compilation. This Rust binary was built on StarFive VisionFive 2. |
yes, we also hit this on loong64 in Debian, the same workaround with setting the env variable worked there, just like it did on riscv64. I will do another round of test builds of 1.82 without the env var set, using the "built-with-workaround" 1.82 builds as stage0. |
skeuchel
added a commit
to skeuchel/nixpkgs
that referenced
this issue
Oct 31, 2024
Change the bootstrap on all platforms to use a version of the upstream binary that is equal to the version that is being built, instead of a binary of one version prior. This is necessary for the 1.82.0 release because on some platforms (rust-lang/rust#129268) the 1.81.0 binary can not build the 1.82.0 source. Furthermore, upstream reported that their development process (now) usually involves building a release compiler with itself and that "the Rust compiler must be able to build itself".
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am trying to build rust compiler from source using default method provided in the documentation for Banana Pi F3 which is RISC-V 64-bit SBC. Operating system is Bianbu 1.0.9 (it is debian based distribution)
I tried this code:
Compiling the rust from the source for riscv64
I expected to see this happen: Install successfully on the desired machine
Instead, this happened: Getting
help: you can increase rustc's stack size by setting RUST_MIN_STACK=2000000000 error: rustc interrupted by SIGSEGV, printing backtraceMeta
rustc --version --verbose:Backtrace (adding full CI pipeline log; also available at [this link](https://dash.cloud-v.co/view/Cloud-V%20Builds/job/cloud-v-builds-folder/job/rust-riscv-build/20/console))
The text was updated successfully, but these errors were encountered: