Tracking Issue for `f16` and `f128` float types #116909

traviscross · 2023-10-18T22:19:47Z

This is a tracking issue for the RFC 3453 (rust-lang/rfcs#3453).

The feature gate for the issue is #![feature(f16_and_f128)].

From the RFC:

This RFC proposes adding new IEEE-compliant floating point types f16 and f128 into the core language and standard library. We will provide a soft float implementation for all targets, and use hardware support where possible.

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Implement the RFC (see the list of tasks here]
Adjust documentation (see instructions on rustc-dev-guide)
Stabilization PR (see instructions on rustc-dev-guide)

Unresolved questions

Do any new target features need to be marked as "forbidden" since they affect ABI? The logic here looks like that may be the case.

Implementation history

Note that unimplemented!("f16_f128") and // FIXME(f16_f128) is being used where relevant, to make the todo list easily greppable.

Nice to have changes:

The text was updated successfully, but these errors were encountered:

tgross35 · 2023-12-09T06:47:38Z

A blocking issue should be added: ensure C compatibility with ABI-cafe or similar

#114607 (comment)

tgross35 · 2024-02-28T18:06:09Z

Implementation steps ~~(could somebody link this in the top post?)~~:

(massive todo list moved to the top post)

@rustbot claim

Enable `f16` for MIPS Blocked on rust-lang/compiler-builtins#762 It seems as if `f16` works on MIPS now according to my testing on Rust master with LLVM 20, and I was asked [here](rust-lang#137167 (comment)) to create PRs with my changes. I only tested on the flavour of `mipsel-unknown-linux-gnu` hardware that happens to be available to me, so I can't say anything about other MIPS hardware, but from a casual skimming of the LLVM code ([1], [2]) it seems like `f16` should work on all MIPS hardware. So enable it for all MIPS hardware. [1]: https://github.com/rust-lang/llvm-project/blob/rustc/20.1-2025-02-13/llvm/lib/Target/Mips/MipsISelLowering.h#L370 [2]: https://github.com/rust-lang/llvm-project/blob/rustc/20.1-2025-02-13/llvm/lib/CodeGen/TargetLoweringBase.cpp#L1367-L1388 `@rustbot` label +O-MIPS +F-f16_and_f128 +S-blocked Tracking issue for f16: rust-lang#116909 r? `@tgross35`

Rollup merge of rust-lang#137311 - martn3:enable-f16-mips, r=tgross35 Enable `f16` for MIPS Blocked on rust-lang/compiler-builtins#762 It seems as if `f16` works on MIPS now according to my testing on Rust master with LLVM 20, and I was asked [here](rust-lang#137167 (comment)) to create PRs with my changes. I only tested on the flavour of `mipsel-unknown-linux-gnu` hardware that happens to be available to me, so I can't say anything about other MIPS hardware, but from a casual skimming of the LLVM code ([1], [2]) it seems like `f16` should work on all MIPS hardware. So enable it for all MIPS hardware. [1]: https://github.com/rust-lang/llvm-project/blob/rustc/20.1-2025-02-13/llvm/lib/Target/Mips/MipsISelLowering.h#L370 [2]: https://github.com/rust-lang/llvm-project/blob/rustc/20.1-2025-02-13/llvm/lib/CodeGen/TargetLoweringBase.cpp#L1367-L1388 `@rustbot` label +O-MIPS +F-f16_and_f128 +S-blocked Tracking issue for f16: rust-lang#116909 r? `@tgross35`

Enable `f16` for LoongArch Blocked on rust-lang/compiler-builtins#770 r? `@tgross35` Tracking issue for f16: rust-lang#116909 try-job: dist-loongarch64-linux try-job: dist-loongarch64-musl

Enable `f16` for LoongArch Blocked on rust-lang/compiler-builtins#770 r? ``@tgross35`` Tracking issue for f16: rust-lang#116909 try-job: dist-loongarch64-linux try-job: dist-loongarch64-musl

Enable `f16` for LoongArch Blocked on rust-lang/compiler-builtins#770 r? ```@tgross35``` Tracking issue for f16: rust-lang#116909 try-job: dist-loongarch64-linux try-job: dist-loongarch64-musl

Rollup merge of rust-lang#137674 - heiher:enable-f16-loong, r=tgross35 Enable `f16` for LoongArch Blocked on rust-lang/compiler-builtins#770 r? ```@tgross35``` Tracking issue for f16: rust-lang#116909 try-job: dist-loongarch64-linux try-job: dist-loongarch64-musl

bjoernager · 2025-03-09T21:26:26Z

Is it possible at this time to implement From<{u8, i8}> for f16 and From<{u8, i8, u16, i16, u32, i32, u64, i64}> for f128?

tgross35 · 2025-03-09T21:40:27Z

That should be possible, we have support in compiler-builtins for the conversions to f128. I don't think LLVM will emit a libcall for i8 to f16 but would need rust-lang/compiler-builtins#729 to work if so, though that isn't a blocker for adding the traits.

I wouldn't get to it for a while but feel free to put up a PR. It's probably worth a crater sanity check considering the issues with #123824, though I don't expect any problems here.

Enable `f16` for MIPS Blocked on rust-lang/compiler-builtins#762 It seems as if `f16` works on MIPS now according to my testing on Rust master with LLVM 20, and I was asked [here](rust-lang#137167 (comment)) to create PRs with my changes. I only tested on the flavour of `mipsel-unknown-linux-gnu` hardware that happens to be available to me, so I can't say anything about other MIPS hardware, but from a casual skimming of the LLVM code ([1], [2]) it seems like `f16` should work on all MIPS hardware. So enable it for all MIPS hardware. [1]: https://github.com/rust-lang/llvm-project/blob/rustc/20.1-2025-02-13/llvm/lib/Target/Mips/MipsISelLowering.h#L370 [2]: https://github.com/rust-lang/llvm-project/blob/rustc/20.1-2025-02-13/llvm/lib/CodeGen/TargetLoweringBase.cpp#L1367-L1388 `@rustbot` label +O-MIPS +F-f16_and_f128 +S-blocked Tracking issue for f16: rust-lang#116909 r? `@tgross35`

…=<try> Add `From<{integer}>` for `f16`/`f128` impls This PR adds `impl From<{bool,i8,u8}> for f16` and `impl From<{bool,i8,u8,i16,u16,i32,u32}> for f128`. The `From<{i64,u64}> for f128` impls are left commented out as adding them would allow using `f128` on stable before it is stabilised like in the following example: ```rust fn f<T: From<u64>>(x: T) -> T { x } fn main() { let x = f(1.0); // the type of the literal is inferred to be `f128` } ``` None of the impls added in this PR have this issue as they are all, at minimum, also implemented by `f64`. This PR will need a crater run for the `From<{i32,u32}>` impls, as `f64` is no longer the only float type to implement them (similar to the cause of rust-lang#125198). cc `@bjoernager` r? `@tgross35` Tracking issue: rust-lang#116909

Enable `f16` for LoongArch Blocked on rust-lang/compiler-builtins#770 r? ```@tgross35``` Tracking issue for f16: rust-lang#116909 try-job: dist-loongarch64-linux try-job: dist-loongarch64-musl

… r=Amanieu Add `From<{integer}>` for `f16`/`f128` impls This PR adds `impl From<{bool,i8,u8}> for f16` and `impl From<{bool,i8,u8,i16,u16,i32,u32}> for f128`. The `From<{i64,u64}> for f128` impls are left commented out as adding them would allow using `f128` on stable before it is stabilised like in the following example: ```rust fn f<T: From<u64>>(x: T) -> T { x } fn main() { let x = f(1.0); // the type of the literal is inferred to be `f128` } ``` None of the impls added in this PR have this issue as they are all, at minimum, also implemented by `f64`. This PR will need a crater run for the `From<{i32,u32}>` impls, as `f64` is no longer the only float type to implement them (similar to the cause of rust-lang#125198). cc `@bjoernager` r? `@tgross35` Tracking issue: rust-lang#116909

…=Amanieu Add `From<{integer}>` for `f16`/`f128` impls This PR adds `impl From<{bool,i8,u8}> for f16` and `impl From<{bool,i8,u8,i16,u16,i32,u32}> for f128`. The `From<{i64,u64}> for f128` impls are left commented out as adding them would allow using `f128` on stable before it is stabilised like in the following example: ```rust fn f<T: From<u64>>(x: T) -> T { x } fn main() { let x = f(1.0); // the type of the literal is inferred to be `f128` } ``` None of the impls added in this PR have this issue as they are all, at minimum, also implemented by `f64`. This PR will need a crater run for the `From<{i32,u32}>` impls, as `f64` is no longer the only float type to implement them (similar to the cause of rust-lang#125198). cc `@bjoernager` r? `@tgross35` Tracking issue: rust-lang#116909

Fallback `{float}` to `f32` when `f32: From<{float}>` and add `impl From<f16> for f32` Currently, the following code compiles: ```rust fn foo::<T: Into<f32>>(_: T) {} fn main() { foo(1.0); } ``` This is because the only `From<{float}>` impl for `f32` is currently `From<f32>`. However, once `impl From<f16> for f32` is added this is no longer the case. This would cause the float literal to fallback to `f64`, subsequently causing a type error as `f32` does not implement `From<f64>`. While this kind of change to type inference isn't technically a breaking change according to Rust's breaking change policy, the previous attempt to add `impl From<f16> for f32` was removed rust-lang#123830 due to the large number of crates affected (by my count, there were root regressions in 42 crates and 52 GitHub repos, not including duplicates). This PR solves this problem by using `f32` as the fallback type for `{float}` when there is a trait predicate of `f32: From<{float}>`. This allows adding `impl From<f16> for f32` without affecting the code that currently compiles (such as the example above; this PR shouldn't affect what is possible on stable). This PR also allows adding a future-incompatibility warning if the lang team wants one; alternatively this could be expanded in the future into something more general like `@tgross35` suggested in rust-lang#123831 (comment). I think it would be also possible to disallow the `f32` fallback in a future edition. This will need a crater check. For reference, I've based the implementation loosely on the existing `calculate_diverging_fallback`. This first commit adds the `f32` fallback and the second adds `impl From<f16> for f32`. I think this falls under the types team, so r? types Fixes: rust-lang#123831 Tracking issue: rust-lang#116909 `@rustbot` label +T-lang +T-types +T-libs-api +F-f16_and_f128 To decide on whether a future-incompatibility warning is desired or otherwise (see above): `@rustbot` label +I-lang-nominated

…ure-gate, r=fmease Fix the `f16`/`f128` feature gates on integer literals The feature gating logic for `f16`/`f128` currently only checks float literals, meaning this code currently compiles with no feature gates on stable ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=b0c0e285ccb822fc7e2abc595557886b)): ```rust fn main() { let a = 1f16; let b = 1f128; dbg!(a, b); } ``` This PR fixes that. Tracking issue: rust-lang#116909

Rollup merge of rust-lang#139294 - beetrees:fix-f16-f128-literal-feature-gate, r=fmease Fix the `f16`/`f128` feature gates on integer literals The feature gating logic for `f16`/`f128` currently only checks float literals, meaning this code currently compiles with no feature gates on stable ([playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=b0c0e285ccb822fc7e2abc595557886b)): ```rust fn main() { let a = 1f16; let b = 1f128; dbg!(a, b); } ``` This PR fixes that. Tracking issue: rust-lang#116909

traviscross added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Oct 18, 2023