Description
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
andf128
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
- Add basic support stubs to IR and backend interfaces: Add stubs in IR and ABI for
f16
andf128
#121728 - Add AST support and intrinsics:
f16
andf128
step 2: intrinsics #121841 (comment) - Connect the frontend, add the feature gate:
f16
andf128
step 3: compiler support & feature gate #121926 - Add the most basic traits that
rustc
more or less expects for primitives Add basic trait impls forf16
andf128
#123085 - Finish support in rustdoc Add
f16
andf128
to rustdoc'sPrimitiveType
#123581 - Add library support.
Some parts are blocked on const eval, compiler builtins updates, and LLVM lowering bugs.hooray, this part is done!-
f16
andf128
step 4: basic library support #122470 - Add a
Debug
impl and some basic functions tof16
andf128
#123783 - Add constants for f16 and f128 #123850
- Add more constants, functions, and tests for
f16
andf128
#126608 - Add classify and related methods for f16 and f128 #127020
- Add
f16
andf128
math functions #127027
-
- Add needed functions to compiler-builtins. Unfortunately this one will block almost everything else on the list.
- Add builtins for
f16
/f128
float conversions compiler-builtins#593 - Add addition, subtraction, multiplication, and compare operations for
f128
compiler-builtins#606 - Add
f128
float to integer conversion functions compiler-builtins#613 - Add f128 int to float conversions compiler-builtins#624
- Add
__divtf3
compiler-builtins#622 - Add
__powitf2
symbol forf128
integer exponentiation compiler-builtins#614 - Others
- Add builtins for
- Figure out parsing and printing
- Migrate the tester to accept more types Rewrite
test-float-parse
in Rust #127510 - Add
f16
, which should be straightforward Addf16
formatting and parsing #127013 - Figure out
f128
which will not be straightforward. Our current implementations are prettyu64
-dependent so they can't fit af128
mantissa. We could make them generic but probably want to instead use an implementation that is slower but better for size.
- Migrate the tester to accept more types Rewrite
- Update const eval
- Basic arithmetic Add
f16
andf128
const eval for binary and unary operationations #126429 - Casting Enable const casting for
f16
andf128
#127032 - Miri shims
- Basic arithmetic Add
- Figure out mangling
Add encoding forAdd v0 symbol mangling forf16
andf128
#122106f16
andf128
#123816 -
Ensure known demanglers get updated or at least have issues for adding the new typesunneeded with the forward-compatible demangling - Add SIMD operations that can make use of these types Add SIMD operations that use f16 and f128 #125440
- Enable assembly registers where it makes sense Enable
f16
andf128
in assembly on platforms that support it #125398 - Make sure the GCC and Clif backends handle these types gracefully
- Support
f16
andf128
rustc_codegen_gcc#461 (merged upstream, waiting on sync) - Support
f16
andf128
rustc_codegen_cranelift#1461 - Migrate float intrinsics to have a fallback (changes from Wishlist: allow adding intrinsics in a way that doesn't break every backend #93145)
- Support
- Make sure all relevant
unimplemented
s andFIXME
s are removed from tools that need library support - Make use of new diagnostic attributes, e.g.
f16_nan
- Figure out ABI & platform-specific problems (thanks @beetrees for just about all of these)
- f16 ABI bugs in compiler-rt
f16
generates code that uses the incorrect ABI for compiler-rt #123885 - 32-bit ABI bugs from LLVM [clang] missing support for _Float128 (C23) llvm/llvm-project#80195 (comment)
- f16 miscompilations from LLVM (affects T2 and T3 targets) LLVM miscompiles consecutive
half
operations by using too much precision on several backends llvm/llvm-project#97975 LLVM miscompiles passing/returninghalf
on several backends by using lossy conversions llvm/llvm-project#97981 - f16 abs and neg quieten signalling NaNs on emulated targets [X86] LLVM >= 18 folding bitcast -> and -> bitcast to
@llvm.fabs.f16
generates call to__extendhfsf2
llvm/llvm-project#104915 (comment) - x86-32 "f16" ABI needs SSE, incompatible with i586 targets #131819
- Tier 1 MinGW incompatibilities from GCC https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054
- Tier2 PowerPC BE precision issues
f128
symbols on powerpc64 give inaccurate results #125109 - Tier2 Power9 possible ABI issues
f128
from_bits
/to_bits
sometimes gets reversed on ppc #125102 - Tier2 PowerPC LE
f128 as f16
casting bug LLVM f128 -> f16 conversion selection failure on powerpc64le llvm/llvm-project#92866 - Tier 2 PowerPC sometimes uses the wrong symbol names PowerPC
fp128
->half
uses__trunctfhf2
but should be__trunckfhf2
llvm/llvm-project#98126 - Tier 2 Loongarch failure to select loongarch64 half (f16) failure to select with
+f
and+d
llvm/llvm-project#93894 (fixed upstream) - Tier 2 arm64ec does not support these types Can't pass or return
half
orfp128
onarm64ec
llvm/llvm-project#94434 - Tier 2 s390x-unknown-linux-gnu doesn't support f16: SystemZ Backend: Add support for operations such as FP16_TO_FP and FP_TO_FP16 llvm/llvm-project#50374
- Tier 2 wasm32 correctness bug On
wasm32
,half
operation results aren't correctly rounded between each operation llvm/llvm-project#96437 - Tier 2 nvptx64-nvidia-cuda doesn't support f128:
fp128
causes compilation failures when compiling fornvptx64-nvidia-cuda
llvm/llvm-project#95471 - Tier 3 mips LLVM crashes with
f128
Compiler crash when targetingmips64
when returningfp128
after calling a function returning{ i8, i128 }
llvm/llvm-project#96432 - Tier 3 sparc-unknown-linux-gnu doesn't support passing f128 directly (error message SPARCv8 does not handle f128 in calls; pass indirectly): Passing long double args on 32-bit SPARC violates ABI llvm/llvm-project#41838
- Tier 3
powerpc64-ibm-aix
doesn't currently supportf128
arguments:fp128
arguments cause a compiler error onpowerpc64-ibm-aix
llvm/llvm-project#101545
- f16 ABI bugs in compiler-rt
- Other misc miscompilations or bugs
- LLVM does
fma.f16
incorrectlyllvm.fma.f16
intrinsic is expanded incorrectly on targets without nativehalf
FMA support llvm/llvm-project#98389 -
powi.f16
constant folding returns incorrect values Misoptimization:EarlyCSEPass
uses replacespowi.f16
withfloat
result llvm/llvm-project#98665
- LLVM does
- Eventually, stabilization
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:
- Better debuginfo for MSVC Improve MSVC debug info for f16 and f128 #121837
- A bit of ecosystem support
- Rust-analyzer Add
f16
andf128
support (add toFloatTy
) rust-analyzer#17451 - Bytemuck Support
f16
andf128
under a nightly flag Lokathor/bytemuck#250 - Zerocopy
- Serde
- num
- rug https://gitlab.com/tspiteri/rug/-/issues/68
- syntax highlighters
- Rust-analyzer Add