Regression: native builds broken on s390x

[uweigand]

After #133050 was merged, all native builds on s390x fail very early during stage0 library build:

Building stage0 library artifacts (s390x-unknown-linux-gnu)
   Compiling core v0.0.0 (/home/uweigand/rust/library/core)
   Compiling rustc-std-workspace-core v1.99.0 (/home/uweigand/rust/library/rustc-std-workspace-core)
   Compiling compiler_builtins v0.1.138
   Compiling libc v0.2.161
   Compiling alloc v0.0.0 (/home/uweigand/rust/library/alloc)
   Compiling cfg-if v1.0.0
   Compiling adler v1.0.2
rustc-LLVM ERROR: Cannot select: 0x3ff58190770: ch = store<(store (s16) into %ir.6), trunc to f16> 0x3ff580a4768, 0x3ff58190850, FrameIndex:i64<2>, undef:i64
  0x3ff58190850: f32,ch = CopyFromReg 0x3ff580a4768, Register:f32 %1
    0x3ff580bdff0: f32 = Register %1
  0x3ff581905b0: i64 = FrameIndex<2>
  0x3ff58190fc0: i64 = undef
In function: _ZN4core3f1621_$LT$impl$u20$f16$GT$5clamp8do_panic7runtime17ha09a9a0f7fcbf036E

Specifically, it looks like the problem was introduced by commit b77dbbd, which adds passing of an argument of type f16 by value.

[RalfJung]

Does adding an #[inline] in this line help?

rust/library/core/src/panic.rs

Line 218 in c00d642

} else #[track_caller] { // Do not inline this, it makes perf worse

[uweigand]

Does adding an #[inline] in this line help?

Yes, it does! With that change the native build completes successfully again.

[saethlin]

s390x-unknown-linux-gnu is a Tier 2 With Host Tools target, so it should not have been possible for this breakage to merge.

@uweigand You are reporting this as a native build failure. I can of course compile a sysroot with -Zbuild-std from x86_64, and I bet that's what we are doing in CI. Do you have any advice on how an interested contributor could get an s390x host to build on? I found some suggestions on how to do this via some casual searching, so I'm just curious if you have a recommended workflow that's publicly available.

[uweigand]

Yes, I also assume this may be a difference between native builds and cross-builds. Do you generally perform native builds for the whole set of supported architectures (even just the Tier 2 With Host Tools ones)?

As to access to a s390x host for test purposes, there are various options; I'd recommend one of the following:

• For temporary access (limited to 120 days), you can register with the "LinuxONE Community Cloud" hosted by Marist College, Poughkeepsie, and then have access to a self-service portal where you can create a s390x machine instance: https://linuxone.cloud.marist.edu/
• For permanent access, you can request a s390x machine here: https://community.ibm.com/zsystems/form/l1cc-oss-vm-request/ (you'll need to describe the open-source project work this machine will be used for, and it'll have to be approved by IBM - but for the purpose of regular testing of the Rust compiler that approval would certainly happen, feel free to mention my name in the request)

In addition, we're currently investigating options of making native s390x builds more directly available via GitHub actions (without you having to set up and manage the host yourself), but that is not yet available today.

[RalfJung]

Yes, it does! With that change the native build completes successfully again.

That is very strange, since #133050 should do exactly that automatically...

... ah! But since you are doing a native build, and #133050 is not applied in the bootstrap compiler, things still break in the stage 0 build.

[RalfJung]

We could add a #[cfg_attr(bootstrap, inline)] to fix this; that shouldn't affect the actually distributed sysroots since those are built at a later stage.

[RalfJung]

Btw @uweigand if IBM could help maintain the s390x LLVM backend, e.g. by fixing selection issues like this, that'd be great. :D

[uweigand]

Btw @uweigand if IBM could help maintain the s390x LLVM backend, e.g. by fixing selection issues like this, that'd be great. :D

Yes, of course. We're already working on adding fp16 support to LLVM (and GCC as well): llvm/llvm-project#109164

This should hopefully be available in LLVM 20.

For any other LLVM issues on s390x always feel free to contact me.

[tgross35]

As to access to a s390x host for test purposes, there are various options; I'd recommend one of the following:

* For temporary access (limited to 120 days), you can register with the "LinuxONE Community Cloud" hosted by Marist College, Poughkeepsie, and then have access to a self-service portal where you can create a s390x machine instance: https://linuxone.cloud.marist.edu/

* For permanent access, you can request a s390x machine here: https://community.ibm.com/zsystems/form/l1cc-oss-vm-request/  (you'll need to describe the open-source project work this machine will be used for, and it'll have to be approved by IBM - but for the purpose of regular testing of the Rust compiler that approval would certainly happen, feel free to mention my name in the request)

Bit of an aside but this sort of thing would be awesome to have in the dev guide, I had no idea these were available but this is great for figuring out test failures.

[tgross35]

I submitted the resource request. I'm not sure whether it is per-user or for the entire organization, but if it is for the org then maybe we can wire it up to our dev desktops somehow (https://forge.rust-lang.org/infra/docs/dev-desktop.html, https://github.com/rust-lang/simpleinfra/tree/master/ansible/roles/dev-desktop)

[uweigand]

Bit of an aside but this sort of thing would be awesome to have in the dev guide, I had no idea these were available but this is great for figuring out test failures.

I've now opened #133577 .

I submitted the resource request. I'm not sure whether it is per-user or for the entire organization, but if it is for the org then maybe we can wire it up to our dev desktops somehow (https://forge.rust-lang.org/infra/docs/dev-desktop.html, https://github.com/rust-lang/simpleinfra/tree/master/ansible/roles/dev-desktop)

This is a (virtual) machine where you have full root access, so you can set this up as you like; as long as ensure the machine will only be accessed and used for the intended purpose (i.e. development of the Rust compiler and open-source ecosystem).