f16/u128 and f16/i128 casts fail to link on macos

[npmccallum]

I tried this code:

1000u128 as f16

I expected to see this happen: successfully compiled and linked.

Instead, this happened: compilation succeeded, but linking failed:

  = note: Undefined symbols for architecture arm64:
            "___floattihf", referenced from:
                __RNvCs5thp3V6xHJg_12f16_i128_bug4main in f16_i128_bug-51851c505ee7ccf3.bzqm8wsrkqjhrmepcg5kajmyx.07dhato.rcgu.o
            "___floatuntihf", referenced from:
                __RNvCs5thp3V6xHJg_12f16_i128_bug4main in f16_i128_bug-51851c505ee7ccf3.bzqm8wsrkqjhrmepcg5kajmyx.07dhato.rcgu.o
          ld: symbol(s) not found for architecture arm64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

See a reproducer here:

https://github.com/npmccallum/f16-i128-bug/

With a failed GitHub Actions run here:

https://github.com/npmccallum/f16-i128-bug/actions/runs/20518578014

This only fails on macOS, either aarch64 or x86_64.

Meta

rustc --version --verbose:

rustc 1.94.0-nightly (fabece9e9 2025-12-25)
binary: rustc
commit-hash: fabece9e9491d0a3c3655dba488881968b7c5f7a
commit-date: 2025-12-25
host: aarch64-apple-darwin
release: 1.94.0-nightly
LLVM version: 21.1.8

[madsmtm]

Odd, __floattihf/__floatuntihf aren't implemented in compiler-rt either.

I get the feeling that this is LLVM's fault, and that it perhaps shouldn't be emitting these symbols in the first place?

[tgross35]

Thanks for the report! This is written up in #132614, though not MacOS specific. I have a branch adding these rust-lang/compiler-builtins#729 but never got around to finishing it (help welcome there).

Odd, __floattihf/__floatuntihf aren't implemented in compiler-rt either.

I get the feeling that this is LLVM's fault, and that it perhaps shouldn't be emitting these symbols in the first place?

Libgcc does have them so compiler-rt probably should too. Doing a single libcall is likely more optimal than ratcheting up, though if you have hardware f16->f64 then doing that before a f64->f128 libcall would be a possible size optimization to avoid needing the f16-specific version.