Background
Support for f16 and f128 is pretty varied across targets (e.g. aarch64 is well supported, arm64ec has zero support), backends (LLVM and GCC support the types with different levels of bugs/crashes, Cranelift does not currently have them enabled), and backend versions (newer versions support more). We can introduce new API without concern because the compiler is automatically inlining relevant functions to prevent codegen, but getting maximum test coverage is problematic.
Ideally we would be testing on every target+backend+version possible, but it is difficult to find a greatest common denominator across all the variety. The current solution is config in std's build.rs https://github.com/rust-lang/rust/blob/c02a4f0852e6665cf3df3867982021383f5615df/library/std/build.rs#L84-L186 which is duplicated in compiler-builtins and libm, but that is very LLVM-specific and can't reflect things that get fixed in newer LLVM versions.
Proposal
Add a target_has_unstable_float option similar to target_has_atomic that will let us query a few different things:
#![feature(target_has_unstable_float)]
#![cfg(target_has_unstable_float = "f16")] // non-broken basic f16 support
#![cfg(target_has_unstable_float = "f16-math")] // math functions work
#![cfg(target_has_unstable_float = "f128")]
#![cfg(target_has_unstable_float = "f128-math")]
The result come from the codegen backends.
This isn't expected to ever stabilize, it's just a way for us to test as much as possible while support is still ramping up.
Mentors or Reviewers
I can implement this.
Process
The main points of the Major Change Process are as follows:
You can read more about Major Change Proposals on forge.
Background
Support for
f16andf128is pretty varied across targets (e.g. aarch64 is well supported, arm64ec has zero support), backends (LLVM and GCC support the types with different levels of bugs/crashes, Cranelift does not currently have them enabled), and backend versions (newer versions support more). We can introduce new API without concern because the compiler is automatically inlining relevant functions to prevent codegen, but getting maximum test coverage is problematic.Ideally we would be testing on every target+backend+version possible, but it is difficult to find a greatest common denominator across all the variety. The current solution is config in std's build.rs https://github.com/rust-lang/rust/blob/c02a4f0852e6665cf3df3867982021383f5615df/library/std/build.rs#L84-L186 which is duplicated in compiler-builtins and libm, but that is very LLVM-specific and can't reflect things that get fixed in newer LLVM versions.
Proposal
Add a
target_has_unstable_floatoption similar totarget_has_atomicthat will let us query a few different things:The result come from the codegen backends.
This isn't expected to ever stabilize, it's just a way for us to test as much as possible while support is still ramping up.
Mentors or Reviewers
I can implement this.
Process
The main points of the Major Change Process are as follows:
@rustbot second.-C flag, then full team check-off is required.@rfcbot fcp mergeon either the MCP or the PR.You can read more about Major Change Proposals on forge.