Revert "Disable f16 on Aarch64 without neon"

[tgross35]

The LLVM issue 1 was resolved and the fix was synced to rust-lang/rust in 2.

This reverts commit c51b229.

try-job: aarch64-gnu
try-job: aarch64-gnu-debug
try-job: armhf-gnu
try-job: dist-various-1

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tgross35]

Needs rust-lang/compiler-builtins#809 to get synced first

@rustbot blocked

[speedy-lex]

This is blocked on #139600

[speedy-lex]

@rustbot ready

[tgross35]

@bors try

[bors]

⌛ Trying commit 4a8d357 with merge 66f0a25...

[bors]

☀️ Try build successful - checks-actions
Build commit: 66f0a25 (66f0a2596f3634b0a1ffd1f8dc314ac5963cb06d)

[Mark-Simulacrum]

r=me unless we think it makes sense to gate this on a "LLVM is at least 20.x.y" -- presumably this is broken on the older LLVM (distro) versions we still support?

[tgross35]

Thanks for taking a look. We haven’t been gating anything anything for the experimental float types based on LLVM version so I think it’s okay to omit here, though that probably isn’t a bad idea to add at some point. In practice these types are likely unreliable with anything other than the latest LLVM, each of the past few versions has come with ABI changes or moderately significant bugfixes.

@bors r=Mark-Simulacrum

[bors]

📌 Commit 4a8d357 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[cuviper]

presumably this is broken on the older LLVM (distro) versions we still support?

For the record, yes, this failed on Fedora 41 (w/ LLVM 19) when compiling the aarch64-unknown-none-softfloat target. Since Fedora uses -DLLVM_UNREACHABLE_OPTIMIZE:BOOL=OFF, we get a trap here:

https://github.com/llvm/llvm-project/blob/cd708029e0b2869e80abe31ddb175f7c35361f90/llvm/lib/Target/AArch64/AArch64ISelLowering.cpp#L26186

Which matches the report in llvm/llvm-project#129394. We don't have full assertions enabled, so it's a SIGTRAP without any message.

I think we'll be able to backport the LLVM fix though: llvm/llvm-project@cb850fe

We haven’t been gating anything anything for the experimental float types based on LLVM version so I think it’s okay to omit here, though that probably isn’t a bad idea to add at some point. In practice these types are likely unreliable with anything other than the latest LLVM, each of the past few versions has come with ABI changes or moderately significant bugfixes.

I wouldn't really care if experimental floats were broken in a "do the wrong thing" kind of way, since nobody should be executing that code yet anyway. But when it fails to compile the target library at all, that's a showstopper IMO.

[tgross35]

You're right; I was thinking it also wouldn't be a problem since we somehow getting correct codegen on LLVM 19, but didn't consider cases where assertions are enabled. I made this conditional in #143125, which I believe you should be able to backport rather than needing to patch LLVM.