Tracking Issue for f16 and f128 float types

@beetrees

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

The feature gate for the issue is #![feature(f16)] and #![feature(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 below section for details)
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.
LLVM seems entirely unable to properly deal with the ABI for these operations, see e.g. this or this. It looks like fixing this will need some non-trivial LLVM changes to pick builtins with the right ABI, or else non-trivial Rust logic to reject e.g. * on f16 if LLVM would get the ABI wrong.
Clang rejects programs that try to use f16 on x86 without SSE. This means we have no template for what extern "C" should do, so maybe we should just reject code that tries to pass such values across extern "C"?

Implementation history and Future Steps

Add basic support stubs to IR and backend interfaces: Add stubs in IR and ABI for f16 and f128 #121728
Add AST support and intrinsics: f16 and f128 step 2: intrinsics #121841 (comment)
Connect the frontend, add the feature gate: f16 and f128 step 3: compiler support & feature gate #121926
Add the most basic traits that rustc more or less expects for primitives Add basic trait impls for f16 and f128 #123085
Finish support in rustdoc Add f16 and f128 to rustdoc's PrimitiveType #123581
Add library support. ~~Some parts are blocked on const eval, compiler builtins updates, and LLVM lowering bugs.~~ hooray, this part is done!
- f16 and f128 step 4: basic library support #122470
- Add a Debug impl and some basic functions to f16 and f128 #123783
- Add constants for f16 and f128 #123850
- Add more constants, functions, and tests for f16 and f128 #126608
- Add classify and related methods for f16 and f128 #127020
- Add f16 and f128 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 for f128 integer exponentiation compiler-builtins#614
- Others
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 Add f16 formatting and parsing #127013
- Figure out f128 which will not be straightforward. Our current implementations are pretty u64-dependent so they can't fit a f128 mantissa. We could make them generic but probably want to instead use an implementation that is slower but better for size.
Update const eval
- Basic arithmetic Add f16 and f128 const eval for binary and unary operationations #126429
- Casting Enable const casting for f16 and f128 #127032
- Miri f16 shims add f16 support miri#4895
- Miri f128 shims (partially implemented by implement sqrt and add fixme for f128 miri#4902)
Figure out mangling ~~Add encoding for f16 and f128 #122106~~ Add v0 symbol mangling for f16 and f128 #123816
~~Ensure known demanglers get updated or at least have issues for adding the new types~~ unneeded with the forward-compatible demangling
Add SIMD operations that can make use of these types Add SIMD operations that use f16 and f128 #125440
- Implement AVX512_FP16 stdarch#1605
- NVPTX: Add f16 SIMD intrinsics stdarch#1626
- others (help welcome)
Enable assembly registers where it makes sense Enable f16 and f128 in assembly on platforms that support it #125398
- Add f16 and f128 inline ASM support for aarch64 #129536
- Add f16 and f128 inline ASM support for x86 and x86-64 #126417
- Add f16 inline ASM support for RISC-V #126530
- Add f16 inline ASM support for 32-bit ARM #126555
- Add f16 inline asm support for LoongArch #142481
- Add f16 inline ASM support for s390x #150826
- Add MSA and f16 inline ASM support for MIPS #160851
- Add floating point inline ASM support for SPARC #160949
- Add f16 and f128 inline ASM support for PowerPC #161135
- Add f16 inline ASM support for nvptx64-nvidia-cuda #161667
- Add f16 inline ASM support to spirv.rs #163281
Add c-variadic support for f128 and validate that it works correctly
- powerpc64 uses an alignment of 16 for f128 (but only of 8 for i128)
Make sure the GCC and Clif backends handle these types gracefully
- Support f16 and f128 rustc_codegen_gcc#461
- Support f16 and f128 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)
Make sure all relevant unimplementeds and FIXMEs are removed from tools that need library support
- Resolve Clippy f16 and f128 unimplemented!/FIXMEs #126636
- Replace f16 and f128 pattern matching stubs with real implementations #123088
- Update f16/f128 FIXMEs that needed (NEG_)INFINITY #127496
Make use of new diagnostic attributes:
- f16_nan Add f16 and f128 to invalid_nan_comparison #132439
- f16_epsilon for Clippy (needs to be added)
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) (checked because I believe these are all tracked elsewhere at this time)
- 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/returning half 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 isn't supported in our baseline x86-32 "f16" ABI needs SSE, incompatible with i586 targets #131819, ABI for float builtins depends on target features llvm/llvm-project#112885
- Tier 1 MinGW f16/f128 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 f16<->f128 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 f128 Can't pass or return half or fp128 on arm64ec llvm/llvm-project#94434 (f16 supported since [Arm64EC] Add support for half llvm/llvm-project#152843)
- Tier 2 aarch64-*-softfloat has crashes with f16 [AArch64] -fp-armv8 crash using select with half llvm/llvm-project#129394
- 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 for nvptx64-nvidia-cuda llvm/llvm-project#95471
- Tier 3 mips LLVM crashes with f128 Compiler crash when targeting mips64 when returning fp128 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 support f128 arguments: fp128 arguments cause a compiler error on powerpc64-ibm-aix llvm/llvm-project#101545
- Generally go through The ABI of float types can be changed by -Ctarget-feature #116344 (and in particular Figure out which target features are required/incompatible for which ABI #131799) for all targets; those issues are mostly focusing on f32 and f64 so there might be more target features we have to worry about for f16/f128 (see f16 and f128 have non-trivial ABI requirements on some targets #138616)
- Intrinsics for minimum and maximum don't work on x86 and aarch64 [aarch64] Cannot select: constant:i128<0> for llvm.maximum.f128 llvm/llvm-project#139380 [x86]: Cannot select: constant:i128<0> for llvm.maximum.f128 llvm/llvm-project#139381 (nonblocking as we are using the fallback for now)
- minimum/maximum for f128 don't work on tier 2 wasm targets f128 on wasm does not support maximum intrinsic #158673
Other misc miscompilations or bugs
- LLVM does fma.f16 incorrectly llvm.fma.f16 intrinsic is expanded incorrectly on targets without native half FMA support llvm/llvm-project#98389
- powi.f16 constant folding returns incorrect values Misoptimization: EarlyCSEPass uses replaces powi.f16 with float result llvm/llvm-project#98665
Implement an internal cfg that lets us gate tests based on backend support Implement the internal feature cfg_target_has_reliable_f16_f128 #140323
Eventually, stabilization

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

Nice to have changes:

Rollup merge of rust-lang#151468 - folkertdev:f16-fixmes, r=tgross35

Unrolled build for #151468

Rollup merge of #151468 - folkertdev:f16-fixmes, r=tgross35

We will provide a soft float implementation for all targets, and use hardware support where possible.

This is bad form. The underyling target should decide if f16 and f128 are support rather than the language. This is how Fortran, C and many other languages are done.

Note I think the gate for f16 and f128 should be independent.
That is have #![feature(f16)] and #![feature(f128)].

They are already, and with the exact naming that you propose. ;)

We will provide a soft float implementation for all targets, and use hardware support where possible.

This is bad form. The underyling target should decide if f16 and f128 are support rather than the language.

It seems that the consensus is to yield such optimisations to the programmer. But this statement also assumes that performance is more important than portability, which is not always the case for all software. Also, even just having the types for storage is useful.

This is how Fortran, C and many other languages are done.

Almost. It is not uncommon for compilers to provide soft floats on some embedded targets. But GCC and Clang, at least, do not seem do so on every target.

We will provide a soft float implementation for all targets, and use hardware support where possible.

This is bad form. The underyling target should decide if f16 and f128 are support rather than the language. This is how Fortran, C and many other languages are done.

I strongly disagree, any pure-computation API that Rust has should work anywhere, that allows code that needs those types to work anywhere even if a bit slowly instead of only wherever the target deigns to provide those types (not that many targets and IIRC some of them need very recent CPUs).

That said, tracking issues aren't the place to have a long discussion, if you want to discuss it more, feel free to create a topic on https://internals.rust-lang.org/ and link it here.

I assume you are coming here from the discussion on a GCC fallback?

We eventually want these types available on all platforms because that shouldn't be the average programmer's concern. Of course the best case scenario is that the platform's ABI tells us exactly what to do, but it's not a good user experience if an otherwise functional library doesn't build on some platform just because they stopped updating their ABI a decade ago. Maybe the library could do something better on platforms that don't support f16/f128, but we'd like that to be a performance concern rather than a "does it work" concern. And then if they do eventually update the ABI, rust can adjust things as needed to match.

I realize this is differs from the usual GCC path which e.g. doesn't support __int128 on i386 since it (despite my efforts) isn't specified there. But I think this is the perfect example where it would be nice if the compiler smoothed things over, because it is inconvenient and measurably bad for performance to roll your own __int128 to implement soft _Float128 ops (which is specified in i386. I'm aware _BitInt exists now.). And GCC also has some extensions.

some targets don't have f16 (even in LLVM).

AFAIK LLVM's half type now works on all targets since LLVM22, using i16 ABI and libcalls as a fallback. f128 still has some work to be done. For reference, we keep track of this at

rust/compiler/rustc_codegen_llvm/src/llvm_util.rs

Lines 374 to 445 in d222ddc

    
           cfg.has_reliable_f16 = match (target_arch, target_os) { 
        
               // LLVM crash without neon <https://github.com/llvm/llvm-project/issues/129394> (fixed in LLVM 20.1.1) 
        
               (Arch::AArch64, _) 
        
                   if !cfg.target_features.iter().any(|f| f.as_str() == "neon") 
        
                       && version < (20, 1, 1) => 
        
               { 
        
                   false 
        
               } 
        
               // Unsupported <https://github.com/llvm/llvm-project/issues/94434> (fixed in llvm22) 
        
               (Arch::Arm64EC, _) if major < 22 => false, 
        
               // Selection failure <https://github.com/llvm/llvm-project/issues/50374> (fixed in llvm21) 
        
               (Arch::S390x, _) if major < 21 => false, 
        
               // MinGW ABI bugs <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054> 
        
               (Arch::X86_64, Os::Windows) if *target_env == Env::Gnu && *target_abi != Abi::Llvm => false, 
        
               // Infinite recursion <https://github.com/llvm/llvm-project/issues/97981> 
        
               (Arch::CSky, _) if major < 22 => false, // (fixed in llvm22) 
        
               (Arch::Hexagon, _) if major < 21 => false, // (fixed in llvm21) 
        
               (Arch::LoongArch32 | Arch::LoongArch64, _) if major < 21 => false, // (fixed in llvm21) 
        
               (Arch::PowerPC | Arch::PowerPC64, _) if major < 22 => false, // (fixed in llvm22) 
        
               (Arch::Sparc | Arch::Sparc64, _) if major < 22 => false, // (fixed in llvm22) 
        
               (Arch::Wasm32 | Arch::Wasm64, _) if major < 22 => false, // (fixed in llvm22) 
        
               // `f16` support only requires that symbols converting to and from `f32` are available. We 
        
               // provide these in `compiler-builtins`, so `f16` should be available on all platforms that 
        
               // do not have other ABI issues or LLVM crashes. 
        
               _ => true, 
        
           }; 
        
           cfg.has_reliable_f128 = match (target_arch, target_os) { 
        
               // Unsupported https://github.com/llvm/llvm-project/issues/121122 
        
               (Arch::AmdGpu, _) => false, 
        
               // Unsupported <https://github.com/llvm/llvm-project/issues/94434> 
        
               (Arch::Arm64EC, _) => false, 
        
               // Selection bug <https://github.com/llvm/llvm-project/issues/96432> (fixed in LLVM 20.1.0) 
        
               (Arch::Mips64 | Arch::Mips64r6, _) if version < (20, 1, 0) => false, 
        
               // Selection bug <https://github.com/llvm/llvm-project/issues/95471>. This issue is closed 
        
               // but basic math still does not work. 
        
               (Arch::Nvptx64, _) => false, 
        
               // ABI bugs <https://github.com/rust-lang/rust/issues/125109> et al. (full 
        
               // list at <https://github.com/rust-lang/rust/issues/116909>) 
        
               (Arch::PowerPC | Arch::PowerPC64, _) => false, 
        
               // ABI unsupported  <https://github.com/llvm/llvm-project/issues/41838> 
        
               (Arch::Sparc, _) => false, 
        
               // Stack alignment bug <https://github.com/llvm/llvm-project/issues/77401>. NB: tests may 
        
               // not fail if our compiler-builtins is linked. (fixed in llvm21) 
        
               (Arch::X86, _) if major < 21 => false, 
        
               // MinGW ABI bugs <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054> 
        
               (Arch::X86_64, Os::Windows) if *target_env == Env::Gnu && *target_abi != Abi::Llvm => false, 
        
               // There are no known problems on other platforms, so the only requirement is that symbols 
        
               // are available. `compiler-builtins` provides all symbols required for core `f128` 
        
               // support, so this should work for everything else. 
        
               _ => true, 
        
           }; 
        
           // Assume that working `f16` means working `f16` math for most platforms, since 
        
           // operations just go through `f32`. 
        
           cfg.has_reliable_f16_math = cfg.has_reliable_f16; 
        
           cfg.has_reliable_f128_math = match (target_arch, target_os) { 
        
               // LLVM lowers `fp128` math to `long double` symbols even on platforms where 
        
               // `long double` is not IEEE binary128. See 
        
               // <https://github.com/llvm/llvm-project/issues/44744>. 
        
               // 
        
               // This rules out anything that doesn't have `long double` = `binary128`; <= 32 bits 
        
               // (ld is `f64`), anything other than Linux (Windows and MacOS use `f64`), and `x86` 
        
               // (ld is 80-bit extended precision). 
        
               // 
        
               // musl does not implement the symbols required for f128 math at all. 
        
               _ if *target_env == Env::Musl => false, 
        
               (Arch::X86_64, _) => false, 
        
               (_, Os::Linux) if target_pointer_width == 64 => true, 
        
               _ => false, 
        
           } && cfg.has_reliable_f128;

.

Regarding where to discuss: the policy is absolutely not for the purpose of ignoring feedback. Things just get cluttered given the lack of threads on GH issues. Discussing on separate issues or at https://rust-lang.zulipchat.com is preferred for that reason, but I'd rather address this here than not at all.

Opened #151557 to continue this thread.

Is there an email list instead? Email has a better interface than anything else?

There is not, Zulip more or less took over the threaded discussion / public archive role.

While it seems that this discussion has been successfully channeled, I am locking this to discourage further reuse of this issue out-of-bounds of strictly "tracking" concerns, per rust-lang/compiler-team#739

If you are not a team member and so cannot speak "over" the lock then you can create a new issue and ping back this one by linking to it. If it constitutes what should be an "unresolved question", "future step", or what-have-you, then a team member can edit that new issue into the tracking issue's initial post. Let all new comments from this point be of a similar procedural or "meta-level" nature.

The maximum intrinsic is missing for wasm targets: #158673

Navigation Menu

Repository navigation

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

About tracking issues

Steps

Unresolved questions

Implementation history and Future Steps

132 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	cfg.has_reliable_f16 = match (target_arch, target_os) {
	// LLVM crash without neon <https://github.com/llvm/llvm-project/issues/129394> (fixed in LLVM 20.1.1)
	(Arch::AArch64, _)
	if !cfg.target_features.iter().any(\|f\| f.as_str() == "neon")
	&& version < (20, 1, 1) =>
	{
	false
	}
	// Unsupported <https://github.com/llvm/llvm-project/issues/94434> (fixed in llvm22)
	(Arch::Arm64EC, _) if major < 22 => false,
	// Selection failure <https://github.com/llvm/llvm-project/issues/50374> (fixed in llvm21)
	(Arch::S390x, _) if major < 21 => false,
	// MinGW ABI bugs <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054>
	(Arch::X86_64, Os::Windows) if target_env == Env::Gnu && target_abi != Abi::Llvm => false,
	// Infinite recursion <https://github.com/llvm/llvm-project/issues/97981>
	(Arch::CSky, _) if major < 22 => false, // (fixed in llvm22)
	(Arch::Hexagon, _) if major < 21 => false, // (fixed in llvm21)
	(Arch::LoongArch32 \| Arch::LoongArch64, _) if major < 21 => false, // (fixed in llvm21)
	(Arch::PowerPC \| Arch::PowerPC64, _) if major < 22 => false, // (fixed in llvm22)
	(Arch::Sparc \| Arch::Sparc64, _) if major < 22 => false, // (fixed in llvm22)
	(Arch::Wasm32 \| Arch::Wasm64, _) if major < 22 => false, // (fixed in llvm22)
	// `f16` support only requires that symbols converting to and from `f32` are available. We
	// provide these in `compiler-builtins`, so `f16` should be available on all platforms that
	// do not have other ABI issues or LLVM crashes.
	_ => true,
	};

	cfg.has_reliable_f128 = match (target_arch, target_os) {
	// Unsupported https://github.com/llvm/llvm-project/issues/121122
	(Arch::AmdGpu, _) => false,
	// Unsupported <https://github.com/llvm/llvm-project/issues/94434>
	(Arch::Arm64EC, _) => false,
	// Selection bug <https://github.com/llvm/llvm-project/issues/96432> (fixed in LLVM 20.1.0)
	(Arch::Mips64 \| Arch::Mips64r6, _) if version < (20, 1, 0) => false,
	// Selection bug <https://github.com/llvm/llvm-project/issues/95471>. This issue is closed
	// but basic math still does not work.
	(Arch::Nvptx64, _) => false,
	// ABI bugs <https://github.com/rust-lang/rust/issues/125109> et al. (full
	// list at <https://github.com/rust-lang/rust/issues/116909>)
	(Arch::PowerPC \| Arch::PowerPC64, _) => false,
	// ABI unsupported <https://github.com/llvm/llvm-project/issues/41838>
	(Arch::Sparc, _) => false,
	// Stack alignment bug <https://github.com/llvm/llvm-project/issues/77401>. NB: tests may
	// not fail if our compiler-builtins is linked. (fixed in llvm21)
	(Arch::X86, _) if major < 21 => false,
	// MinGW ABI bugs <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054>
	(Arch::X86_64, Os::Windows) if target_env == Env::Gnu && target_abi != Abi::Llvm => false,
	// There are no known problems on other platforms, so the only requirement is that symbols
	// are available. `compiler-builtins` provides all symbols required for core `f128`
	// support, so this should work for everything else.
	_ => true,
	};

	// Assume that working `f16` means working `f16` math for most platforms, since
	// operations just go through `f32`.
	cfg.has_reliable_f16_math = cfg.has_reliable_f16;

	cfg.has_reliable_f128_math = match (target_arch, target_os) {
	// LLVM lowers `fp128` math to `long double` symbols even on platforms where
	// `long double` is not IEEE binary128. See
	// <https://github.com/llvm/llvm-project/issues/44744>.
	//
	// This rules out anything that doesn't have `long double` = `binary128`; <= 32 bits
	// (ld is `f64`), anything other than Linux (Windows and MacOS use `f64`), and `x86`
	// (ld is 80-bit extended precision).
	//
	// musl does not implement the symbols required for f128 math at all.
	_ if *target_env == Env::Musl => false,
	(Arch::X86_64, _) => false,
	(_, Os::Linux) if target_pointer_width == 64 => true,
	_ => false,
	} && cfg.has_reliable_f128;

Tracking Issue for f16 and f128 float types #116909

Description

About tracking issues

Steps

Unresolved questions

Implementation history and Future Steps

Activity

traviscross commented on Oct 18, 2023

traviscross commented on Oct 19, 2023

tgross35 commented on Oct 19, 2023

gorentbarak commented on Oct 27, 2023

gorentbarak commented on Oct 27, 2023

gorentbarak commented on Oct 27, 2023

gorentbarak commented on Oct 27, 2023

rustbot commented on Oct 27, 2023

gorentbarak commented on Oct 27, 2023

132 remaining items

pinskia commented on Jan 23, 2026

pinskia commented on Jan 23, 2026

bjoernager commented on Jan 23, 2026

programmerjake commented on Jan 23, 2026

pinskia commented on Jan 23, 2026

bjoernager commented on Jan 23, 2026

tgross35 commented on Jan 23, 2026

pinskia commented on Jan 23, 2026

tgross35 commented on Jan 23, 2026

workingjubilee commented on Jan 25, 2026

ChrisDenton commented on Jul 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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