ci: Move dist-aarch64-linux to an aarch64 runner

[mrkajetanp]

Move the dist-aarch64-linux CI job to an aarch64 runner instead of cross-compiling it from an x86 one. This will make it possible to perform optimisations such as LTO, PGO and BOLT later on.

r? @Kobzol

Reland of #133809 now that the higher page sizes are fixed.

try-job: dist-aarch64-linux
try-job: dist-x86_64-linux
try-job: dist-i686-linux

[mrkajetanp]

Same as before, plus a couple small changes to account for the LTO+clang workarounds that were merged in the meantime

[tgross35]

@bors try

[bors]

⌛ Trying commit 7d9903c with merge a8e7b21...

[bors]

💥 Test timed out

[mrkajetanp]

Do we need a longer timeout here again?

[Kobzol]

We probably turned that one to a free runner recently-ish, so it times out now. With the cache primed, it should be fine.

@bors try

[bors]

⌛ Trying commit 7d9903c with merge 4c7352d...

[bors]

☔ The latest upstream changes (presumably #135286) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

💥 Test timed out

[mrkajetanp]

Ahh I see, I think we need to apply the same fix as in #134690 to i686 as well.

But then it already seems like it was tested there when that PR was merged? build-clang.sh is failing with some errors mentioning Gold and that's causing the timeout in any case.

[tgross35]

There is the path src/ci/docker/host-*/disabled for jobs that are still useful but don't run in CI. I'm not sure what the policy is, but maybe it would be good to move this there instead of removing it? I would find it occasionally useful for verifying aarch64 builds on x86 machines. (non-dist would be better yet, but leaving the dist job around still seems convenient).

[Kobzol]

Jobs in the disabled directory rot fast, and they can be restored from git history, so I personally don't see a lot of value in this. You can always copy-paste the contents locally to test it.

[Kobzol]

It seems to me that this is the only change that happened to the 32-bit runner. I think that the problem is that only the 64-bit version of binutils is installed in the CentOS image:

2025-01-09T14:25:36.9324939Z #13 5.216 ---> Package binutils.x86_64 0:2.27-44.base.el7 will be updated
2025-01-09T14:25:36.9325811Z #13 5.217 ---> Package binutils.x86_64 0:2.27-44.base.el7_9.1 will be an update

So either this should be reverted (keep it hardcoded for 64-bit), or the 32-bit image should install also the 32-bit version of binutils.

[mrkajetanp]

I'm fairly sure the problem is here

-DLLVM_BINUTILS_INCDIR="/rustroot/lib/gcc/$GCC_BUILD_TARGET/$GCC_VERSION/plugin/include/" \

Because GCC_BUILD_TARGET will be i686 for the i686 job but the plugin/include will end up under x86_64 because that's where the job is running. I'm running a local build to confirm atm

[Kobzol]

I don't think that the cause is necessarily that the host is x64, rather than just the binutils package is installed only in the x64 version, not the i686 version. So downloading a binutils.i686 CentOS package should hopefully fix it. If not, I would just hardcode the previous x64 path.

[rustbot]

Some changes occurred in src/tools/cargo

cc @ehuss

[mrkajetanp]

ah sorry about that

[Kobzol]

It seems like you did both, i.e. install 32-bit binutils, but use the x64 path? :D

Anyway, let's see if it helped.

@bors try

[bors]

⌛ Trying commit 307480a with merge c2013d9...

[mrkajetanp]

Well I figured the builds take so long to run that I might as well try the more conservative approach :) I think if it needed the i686 binutils it probably would have failed sooner, but it failing on the linking stage of building clang suggests that it's the linker plugin include that was messed up

[bors]

☀️ Try build successful - checks-actions
Build commit: c2013d9 (c2013d90324bd57e903ea300e181b37f130d4b74)

[bors]

⌛ Testing commit 9ba34f8 with merge 724f36a...

[rust-log-analyzer]

The job dist-x86_64-msvc failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

💔 Test failed - checks-actions

[mrkajetanp]

Huh, I don' think this is related to the PR?

2025-01-11T21:44:43.5293056Z �[1m�[31merror�[0m�[1m:�[0m failed to remove file `C:\a\rust\rust\build\x86_64-pc-windows-msvc\stage1-rustc\x86_64-pc-windows-msvc\release\rustc-main.exe`
2025-01-11T21:44:43.5293778Z 
2025-01-11T21:44:43.5293891Z Caused by:
2025-01-11T21:44:43.5294173Z   Access is denied. (os error 5)

But then I know nothing about windows, so if someone who does could chime in that'd be great..

[Kobzol]

Yeah, that's sadly a known flaky failure.

@bors retry

[bors]

⌛ Testing commit 9ba34f8 with merge afb3e7e...

[rust-log-analyzer]

The job x86_64-gnu-llvm-19-1 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

[bors]

💔 Test failed - checks-actions

[mrkajetanp]

It seems the CI gods are not with us tonight

2025-01-12T02:33:21.7595180Z �[1m�[31merror�[0m�[1m:�[0m failed to download from `https://static.crates.io/crates/rand_xorshift/0.3.0/download`
2025-01-12T02:33:21.7595798Z 
2025-01-12T02:33:21.7595923Z Caused by:
2025-01-12T02:33:21.7596566Z   [7] Could not connect to server (Failed to connect to static.crates.io port 443 after 1019 ms: Could not connect to server)
2025-01-12T02:33:21.7619188Z Build completed unsuccessfully in 0:57:06

[Kobzol]

@bors retry

[bors]

⌛ Testing commit 9ba34f8 with merge c0f6a1c...

[bors]

☀️ Test successful - checks-actions
Approved by: Kobzol
Pushing c0f6a1c to master...

[rust-timer]

Finished benchmarking commit (c0f6a1c): comparison URL.

Overall result: ✅ improvements - no action needed

@rustbot label: -perf-regression

Instruction count

This is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-0.3%	[-0.4%, -0.3%]	3
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

This benchmark run did not return any relevant results for this metric.

Cycles

Results (secondary -3.0%)

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.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-3.0%	[-3.0%, -3.0%]	1
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 761.975s -> 761.573s (-0.05%)
Artifact size: 326.11 MiB -> 326.13 MiB (0.01%)