Missing cfg(target_has_reliable_f16_math) check for f16 tests

[bjorn3]

#513 added a bunch of f16 tests, which fail to link with cg_clif on x86_64-pc-windows-gnu due to missing intrinsics. cg_clif does declare f16 support as unreliable on this target, but portable-simd never checks it. This causes CI to fail for the rustc update. https://github.com/rust-lang/rustc_codegen_cranelift/actions/runs/24462910206/job/71481840311

[bjorn3]

cc @folkertdev

[folkertdev]

So, we do want to get rid of target_has_reliable_f16_math soon, what would it take to provide those intrinsics?

For now we can just not build the tests on that target when the flag is false. We already have to work around an LLVM bug on wasm32 that can't build the tests either. I'll make a PR.

[bjorn3]

For some casting to f32 and back may work, but I don't know if that works for all intrinsics and if not for which ones it doesn't work.

[folkertdev]

well so far it only mentions ceilf16 and floorf16, but maybe it stopped early? I think using f32 for them should be fine.

cc @tgross35

[tgross35]

Huh, how is that test passing at all on win-gnu with LLVM? That still has the ABI mismatch https://github.com/rust-lang/rust/blob/18b439f84ec0b087283bac3356a1eeac53c60c5e/compiler/rustc_codegen_llvm/src/llvm_util.rs#L376-L379.

c-b does provide the symbols https://github.com/rust-lang/compiler-builtins/blob/2a1d43e53966f27f4ba6e7bd3e0c526a3b54a412/compiler-builtins/src/math/mod.rs#L23-L42 but they are gated. In general I think the approach here is the right one, no need to replicate the logic across all backends of which operations work via promotion. rust-lang/rust#150946 will make that easier but I need to get it over the line...

[folkertdev]

In #520 we're running into the problem actually being in proptest, which specifically needs floorf16 and ceilf16, which should like they should be relatively straightforward to implement/provide?

the approach here is the right one

To clarify, you propose that c-b should provide the symbols in this case? And there is some technical reason that this doesn't currently happen?

[folkertdev]

Huh, how is that test passing at all on win-gnu with LLVM?

A test you don't run cannot fail :) CI on this repo only runs windows with msvc apparently, and I guess r-l/r does not run the portable_simd tests?

[tgross35]

In #520 we're running into the problem actually being in proptest, which specifically needs floorf16 and ceilf16, which should like they should be relatively straightforward to implement/provide?

the approach here is the right one

To clarify, you propose that c-b should provide the symbols in this case? And there is some technical reason that this doesn't currently happen?

We do have the simple f16 symbols on most targets, my second link above is where we list what to export.

ls -d $(rustc --print sysroot)/lib/rustlib/x86_64-unknown-linux-gnu/lib/* | grep compiler_builtins.*.rlib | xargs llvm-nm -g | grep 'f16$'
0000000000000000 W sqrtf16
0000000000000000 W fmodf16
0000000000000000 W ceilf16
0000000000000000 W floorf16
0000000000000000 W roundf16
0000000000000000 W truncf16
0000000000000000 W fmaximum_numf16
0000000000000000 W fminimum_numf16
0000000000000000 W rintf16
0000000000000000 W roundevenf16
0000000000000000 W fminimumf16
0000000000000000 W fmaximumf16
0000000000000000 W fmaxf16
0000000000000000 W fminf16
0000000000000000 W copysignf16
0000000000000000 W fdimf16
0000000000000000 W fabsf16

They aren't on windows-gnu because that's the last one to not set cfg(target_has_reliable_f16). Because of the ABI thing, I wouldn't expect tests to pass regardless of backend (unless it's running on a MinGW prerelease or something).

[folkertdev]

Right, but it would turn the issue into a runtime error instead of a build failure. At least here that would be convenient, though I can see how it might mask issues.