Add integer to f16 conversions

[npmccallum]

Add integer to f16 conversions

LLVM emits __float{,un}sihf, __float{,un}dihf and __float{,un}tihf
when converting 32-, 64- and 128-bit integers to f16, but compiler-builtins
never provided them (they are not in LLVM's compiler-rt either). Code doing
int as f16 therefore fails to link on any target without another provider of
these symbols — for example musl or macos. glibc targets only link because
libgcc happens to supply them. This is the compiler-builtins side of
rust-lang/rust#132614 (part of the tracking issue rust-lang/rust#116909); it
will resolve that issue once synced into the rust-lang/rust subtree.

Credit

The conversion routines here are Trevor Gross's work from #729, which has been
open since 2024-11. That PR was complete on the implementation side but stalled
on a single question about its test oracle. This PR carries his implementation
forward with him listed as Co-authored-by:, proposes an answer to that
question, and adds the missing link coverage. Thanks @tgross35 for the original
implementation — this is intended to supersede #729, and I'm happy to fold it
back into that PR instead if you'd prefer.

Approach

Three commits, each doing one thing:

1. test: exercise 128-bit integer to f16 link paths — adds the six
   integer-to-f16 cases to builtins-test-intrinsics, which links every
   intrinsic LLVM may emit. This commit intentionally fails to link (the
   symbols don't exist yet), reproducing the exact failure real user code hits
   on musl/macos.

2. feat(float): add integer to f16 conversions — implements all six
   routines by reusing the existing left-align / round-to-even machinery.
   Unlike wider float types, any integer can overflow f16's exponent range,
   so each routine clamps to infinity once the rounded exponent saturates.
   This turns commit 1 green.

3. test(float): validate int-to-f16 rounding via apfloat — exercises the
   new routines and fixes the rounding oracle so f16 can be checked at all.

Commit 1 intentionally fails to link on its own. I've kept it that way because
it documents the defect as a bisectable red→green and mirrors what user code
currently hits — but builtins-test-intrinsics is excluded from the workspace,
so the library and default members still build at that commit. If the project
would rather avoid a non-building commit in history, I'm happy to reorder so the
implementation lands first, keeping the link test as its own commit but green.

The oracle change (the question #729 stalled on)

The i_to_f rounding check reconstructed an error bracket by casting the float
result and its neighbours back to integers. That saturates inf to iN::MAX,
so for f16 the bracket is meaningless: f16::MAX (65504) is far closer to 0
than any iN::MAX for N ≥ 32, and every correctly-overflowing conversion was
flagged as mis-rounded. No wider float type hits this, which is why the bracket
went unchallenged.

This compares the builtin's result directly against rustc_apfloat — a
correctly-rounded oracle already used on the fallback path. Overflow to
infinity falls out naturally: apfloat rounds with an unbounded exponent and
applies the overflow threshold afterwards, so the expected bit pattern is inf
exactly when the builtin must return it. This replaces the bracket for all
widths, not just f16, and is the minimal change that lets the f16 tests be
correct rather than a special-case skip.

Verification

• Commit 1 alone fails to link (undefined symbol: __floatuntihf,
  __floattihf); commit 2 links cleanly on both glibc and musl.
• All 41 conv tests pass, including the six new f16 cases; f32/f64/f128 are
  unchanged.
• The old bracket oracle, applied to the new f16 tests, fails all six with
  the saturation signature (inf → u32::MAX); the apfloat oracle passes them.
• rustfmt and clippy clean under -Dwarnings.
• The f16 <-> int system routines are gated off on targets that lack them
  (apple, windows), matching the existing no-sys-* handling.

The ti variants carry #[cfg_attr(target_os = "uefi", unadjusted_on_win64)]
to match their sf/df siblings.

[tgross35]

Thank you for picking this up! I think the test bits are fine but Juho understood the issue better than me.

Totally fine to supersede my PR but mind picking df3c10a directly? I split off the conflict-y bit.

View changes since this review

[tgross35]

@quaternic would you mind reviewing this portion?

[npmccallum]

Thanks @tgross35, and thanks for splitting off df3c10a — I did try to take it directly. The snag is that it's the Nov-2024 version, so it conflicts against current main in conv.rs, and its test block uses the old feature = "no-sys-f16-int-convert" cfg (now no_sys_f16_int_convert via build.rs) plus the original bracket oracle — so taking it verbatim would either reintroduce the conflict or leave an intermediate commit that's red on f16, which I wanted to avoid for a clean history.

What I've done instead: kept the equivalent implementation but set you as the author of the conversions commit (I'm listed as co-author), so the primary credit is yours. It's the same six routines; the only deltas from df3c10a are dropping the unrelated reordering churn and adding #[cfg_attr(target_os = "uefi", unadjusted_on_win64)] on the ti→hf variants for parity with their sf/df siblings. The rounding oracle follows Juho's diagnosis — apfloat directly instead of the f→i bracket.

Happy to adjust the attribution however you'd prefer. Thanks again for the original work here.