ci: use GCC 13 as cross compiler in dist-aarch64-linux
#125999
Conversation
I'm proposing this GCC upgrade since it addresses bug rust-lang#125619. The regression in question affects stable release consumers who tend to have no exposure to Rust build tools, so if at all possible, I would like to have it resolved in the next stable release. I have tried to fix the bug in `compiler-builtins`, which led to submitting a PR for `compiler-rt` in upstream LLVM, but it may take a long time before these upstreams address this regression. A summary of why upgrading GCC solves the regression follows. `__multc3()` is a builtin function `compiler-builtins` exposes for specifically aarch64, non-Windows targets [1]. The object file for it is included in `staticlib` archives through `libstd`. The implementation for `__multc3()` is from `multc3.c`, part of LLVM's `compiler-rt`. Upstream `compiler-rt` normally builds the C file using the Clang from the same LLVM version. On the other hand, `compiler-builtins` builds the C file using GCC, outside of the usual LLVM build system. The upstream implementation doesn't have feature detection which works for GCC version older than 10, and ends up producing an unlinkable object. Upstream LLVM might be slow to respond to this issue as they might deem `compiler-builtin` as doing something out of the ordinary from their perspective. They might reasonably assume everyone builds `compiler-rt` through LLVM's build system. I have done the following to test this change: - verified that a local build without this patch exhibits the regression. - verified that with this patch, the object for `__multc3()` has no reference to undefined functions in the symbol table. - verified that with this patch, `rustc` is usable to build Ruby with YJIT, and that the reported regression is resolved. [1]: https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L524-L539
rustbot
added
A-testsuite
|
@cuviper You have last touched the crosstool-ng configuration :) Do you think it's fine in general to upgrade GCC from 8 to 13, is the old(er) version important for anything specific? I seem to recall some issues with updating GCC too much on the x64 Linux runner. |
|
@Kobzol I'm not sure what issues you're recalling, but there is some risk of symbol versioning trouble with ... and there are more for |
|
Thanks for checking! I think I remembered now - the issue just was that GCC 9+ couldn't be built with GCC 4, that we use on CI. But that shouldn't be an issue for crosstool. |
|
I don't know if I have permissions to do this, but I'm curious if this passes CI. @bors try |
|
@XrXr: 🔑 Insufficient privileges: not in try users |
|
@bors try |
ci: use GCC 13 as cross compiler in `dist-aarch64-linux` I'm proposing this GCC upgrade since it addresses bug rust-lang#125619. The regression in question affects stable release consumers who tend to have no exposure to Rust build tools, so if at all possible, I would like to have it resolved in the next stable release. I have tried to fix the bug in `compiler-builtins`, which led to submitting a PR for `compiler-rt` in upstream LLVM, but it may take a long time before these upstreams address this regression. A summary of why upgrading GCC solves the regression follows. `__multc3()` is a builtin function `compiler-builtins` exposes for specifically aarch64, non-Windows targets [1]. The object file for it is included in `staticlib` archives through `libstd`. The implementation for `__multc3()` is from `multc3.c`, part of LLVM's `compiler-rt`. Upstream `compiler-rt` normally builds the C file using the Clang from the same LLVM version. On the other hand, `compiler-builtins` builds the C file using GCC, outside of the usual LLVM build system. The upstream implementation doesn't have feature detection which works for GCC version older than 10, and ends up producing an unlinkable object. Upstream LLVM might be slow to respond to this issue as they might deem `compiler-builtin` as doing something out of the ordinary from their perspective. They might reasonably assume everyone builds `compiler-rt` through LLVM's build system. I have done the following to test this change: - verified that a local build without this patch exhibits the regression. - verified that with this patch, the object for `__multc3()` has no reference to undefined functions in the symbol table. - verified that with this patch, `rustc` is usable to build Ruby with YJIT, and that the reported regression is resolved. Since `loongarch64-linux-gnu` already uses GCC 13.2.0, I hope we can upgrade without issues. try-job: dist-aarch64-linux [1]: https://github.com/rust-lang/compiler-builtins/blob/c04eb9e1afb72bdf943f5e5d77b3812f40526602/build.rs#L524-L539
Ooh, I haven't seen that in action yet, neat! |
|
☀️ Try build successful - checks-actions |
|
CI job looked ok, and beta has just branched, so let's merge and see if it causes any problems downstream. @bors r+ rollup=never |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (65d1a73): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)This benchmark run did not return any relevant results for this metric. CyclesResults (secondary -7.5%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: missing data |
I'm proposing this GCC upgrade since it addresses bug #125619. The
regression in question affects stable release consumers who tend to have
no exposure to Rust build tools, so if at all possible, I would like to
have it resolved in the next stable release. I have tried to fix the bug
in
compiler-builtins, which led to submitting a PR forcompiler-rtin upstream LLVM, but it may take a long time before these upstreams
address this regression.
A summary of why upgrading GCC solves the regression follows.
__multc3()is a builtin functioncompiler-builtinsexposes forspecifically aarch64, non-Windows targets 1. The object file for it is
included in
staticlibarchives throughlibstd. The implementationfor
__multc3()is frommultc3.c, part of LLVM'scompiler-rt.Upstream
compiler-rtnormally builds the C file using the Clangfrom the same LLVM version. On the other hand,
compiler-builtinsbuilds the C file using GCC, outside of the usual LLVM build system.
The upstream implementation doesn't have feature detection which
works for GCC version older than 10, and ends up producing an
unlinkable object.
Upstream LLVM might be slow to respond to this issue as they might deem
compiler-builtinas doing something out of the ordinary from theirperspective. They might reasonably assume everyone builds
compiler-rtthrough LLVM's build system.
I have done the following to test this change:
regression.
__multc3()has noreference to undefined functions in the symbol table.
rustcis usable to build Ruby withYJIT, and that the reported regression is resolved.
Since
loongarch64-linux-gnualready uses GCC 13.2.0, I hope we can upgrade without issues.try-job: dist-aarch64-linux