Merge `fabsf16/32/64/128` into `fabs::<F>` by N1ark · Pull Request #153834 · rust-lang/rust

N1ark · 2026-03-13T19:22:35Z

Following a small conversation on Zulip (and because I'd be interested in starting to contribute on Rust), I thought I'd give a try at merging the float intrinsics :)

This PR just merges fabsf16, fabsf32, fabsf64, fabsf128, as it felt like an easy first target.

Notes:

I'm opening the PR for one intrinsic as it's probably easier if the shift is done one intrinsic at a time, but let me know if you'd rather I do several at a time to reduce the number of PRs.
Currently this PR increases LOCs, despite being an attempt at simplifying the intrinsics/compilers. I believe this increase is a one time thing as I had to define new functions and move some things around, and hopefully future PRs/commits will reduce overall LoCs
fabsf32 and fabsf64 are #[rustc_intrinsic_const_stable_indirect], while fabsf16 and fabsf128 aren't; because f32/f64 expect the function to be const, the generic version must be made indirectly stable too. We'd need to check with T-lang this change is ok; the only other intrinsics where there is such a mismatch is minnum, maxnum and copysign.
I haven't touched libm because I'm not familiar with how it works; any guidance would be welcome!

rustbot · 2026-03-13T19:22:38Z

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

Some changes occurred to the CTFE / Miri interpreter

cc @rust-lang/miri

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

rustbot · 2026-03-13T19:22:40Z

r? @TaKO8Ki

rustbot has assigned @TaKO8Ki.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 69 candidates
Random selection from 15 candidates

tgross35 · 2026-03-13T19:29:00Z

r? tgross35

N1ark · 2026-03-13T20:25:13Z

ah oops i was wondering why gcc wasn't working locally, guess it never installed :') ill fix this soon

scottmcm · 2026-03-13T20:41:52Z

library/core/src/intrinsics/mod.rs

-#[rustc_nounwind]
-#[rustc_intrinsic]
-pub const fn fabsf128(x: f128) -> f128;
+pub const fn fabs<T: Copy>(x: T) -> T;


suggestion: like there's

rust/library/core/src/intrinsics/bounds.rs

Lines 5 to 25 in f1ceedf

/// Types with a built-in dereference operator in runtime MIR,

/// aka references and raw pointers.

///

/// # Safety

/// Must actually *be* such a type.

pub unsafe trait BuiltinDeref: Sized {

type Pointee: PointeeSized;

}

unsafe impl<T: PointeeSized> BuiltinDeref for &mut T {

type Pointee = T;

}

unsafe impl<T: PointeeSized> BuiltinDeref for &T {

type Pointee = T;

}

unsafe impl<T: PointeeSized> BuiltinDeref for *mut T {

type Pointee = T;

}

unsafe impl<T: PointeeSized> BuiltinDeref for *const T {

type Pointee = T;

}

, consider adding a trait there just to help emphasize that this is for floats only, so this could be

Suggested change

pub const fn fabs<T: Copy>(x: T) -> T;

pub const fn fabs<T: bounds::FloatPrimitive>(x: T) -> T;

or similar.

Fixed in 74114c9; also added it to the other generic float intrinsics

note this changes the diagnostic when these intrinsics are misused: it now gives a type error (see 043f9ad) rather than a monomorphization error; i think this is a good thing :)

scottmcm · 2026-03-13T20:45:05Z

compiler/rustc_codegen_cranelift/src/intrinsics/mod.rs

+                ty::Float(FloatTy::F32) | ty::Float(FloatTy::F64) => fx.bcx.ins().fabs(x),
+                // FIXME(bytecodealliance/wasmtime#8312): Use `fabsf16` once Cranelift
+                // backend lowerings are implemented.
+                ty::Float(FloatTy::F16) => codegen_f16_f128::abs_f16(fx, x),


pondering: these make me wonder if it'd be worth just having fallback mir for this?

See how there's

pub const unsafe fn disjoint_bitor<T: [const] fallback::DisjointBitOr>(a: T, b: T) -> T {

for example to give that one a fallback; might be reasonable to do the same for fabs (since it's easy to implement) and backends can just fallback to that if they haven't implemented it natively for f16/f128 yet.

(That said, it's a copysign+fabs thing only, really, since fallback MIR for most float ops is probably not a good idea. fpow is hard.)

I'd like to have fallbacks for all of these via libcalls; have some of that in progress at #150946.

abs and copysign probably shouldn't use the libcalls though, they can copy the implementation from https://github.com/rust-lang/compiler-builtins/blob/85db9f1923007c287b894d392b880545ec70d05e/libm/src/math/generic/fabs.rs and https://github.com/rust-lang/compiler-builtins/blob/85db9f1923007c287b894d392b880545ec70d05e/libm/src/math/generic/copysign.rs.

compiler/rustc_codegen_llvm/src/intrinsic.rs

compiler/rustc_codegen_gcc/src/intrinsic/mod.rs

N1ark · 2026-03-14T11:30:16Z

btw; I saw in rustc_codegen_ssa there's two different errors relating to expecting float types; I picked BasicFloatType because in the same function BasicIntegerType is raised, but I'm curious if there's any reason to have both of these rather than merging them :) (FloatingPointType is only used in a couple places relating to SIMD intrinsics)

rust/compiler/rustc_codegen_ssa/src/errors.rs

Lines 718 to 724 in 620e36a

    
           #[diag("invalid monomorphization of `{$name}` intrinsic: expected basic float type, found `{$ty}`", code = E0511)] 
        
           BasicFloatType { 
        
               #[primary_span] 
        
               span: Span, 
        
               name: Symbol, 
        
               ty: Ty<'tcx>, 
        
           },

rust/compiler/rustc_codegen_ssa/src/errors.rs

Lines 742 to 748 in 620e36a

    
           #[diag("invalid monomorphization of `{$name}` intrinsic: `{$in_ty}` is not a floating-point type", code = E0511)] 
        
           FloatingPointType { 
        
               #[primary_span] 
        
               span: Span, 
        
               name: Symbol, 
        
               in_ty: Ty<'tcx>, 
        
           },

RalfJung · 2026-03-14T11:47:52Z

The diagnostic error types are quite the mess there, feel free to adjust or replace them by string-based errors if that simplifies the code.

N1ark · 2026-03-14T12:54:54Z

The diagnostic error types are quite the mess there, feel free to adjust or replace them by string-based errors if that simplifies the code.

fair enough :) removed the duplicate in ebb6dfb

scottmcm · 2026-03-15T03:13:20Z

I saw in rustc_codegen_ssa there's two different errors relating to expecting float types

Misuse of intrinsics falls under rust-lang/compiler-team#620 -- you can feel free to rip out any inconvenient errors entirely and just have them ICE.

library/core/src/intrinsics/mod.rs

compiler/rustc_const_eval/src/interpret/intrinsics.rs

RalfJung · 2026-03-15T10:52:53Z

library/core/src/intrinsics/mod.rs

-#[rustc_nounwind]
-#[rustc_intrinsic]
-pub const fn fabsf128(x: f128) -> f128;
+pub const fn fabs<T: bounds::FloatPrimitive>(x: T) -> T;


@rust-lang/lang this would mark fabs as indirectly const stable for all float types, not just f32 and f64. The const implementation is uniform across all types so I have no concerns about this -- the f16 and f128 implementation is and has been ready for stable for a while, it's the non-const implementation of f16 and f128 that's not ready. ;)

Nevertheless, new intrinsics being available to stable const code requires lang approval. Not sure if you think a full FCP is required for a trivial case like this.

btw if a FCP is required, we should throw in copysign in there, which is in the same situation: const stable for f32/f64 but not for f16/f128, and it's also a binary operation

We should probably throw in all the intrinsics you intend to generalize that are easily implemented with apfloat. Do you have a list of them?

Oh, I didn't realize all the f16/f128 rounding methods have already been allowed in const-stable since #143604. That may have been an accident, but it's also not really a problem.

yep, it's fabs, copysign, minnum and maxnum; all other float intrinsics are all const stable across all float types or not const stable for any

Personally (with my lang hat on but not speaking as team consensus) I would be fine treating this as "the previous FCP was saying that floating-point abs is allowed to be const-stable -- because it's easy to do reliably in const, being that it's only bitwise (without even NAN nondet, IIRC?) -- and how exactly that translates to specific intrinsics is a compiler/ctfe question without needing addtional lang FCPs".

But we'll see what the meeting says on Wed.

without even NAN nondet, IIRC?

Correct, fabs just mutates the sign bit and nothing else.

rust-rfcbot · 2026-03-28T15:16:09Z

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

RalfJung · 2026-03-28T17:04:48Z

@bors r=tgross35,RalfJung

rust-bors · 2026-03-28T17:04:50Z

📋 This PR cannot be approved because it currently has the following label: S-waiting-on-fcp.

RalfJung · 2026-03-28T17:05:05Z

@bors r=tgross35,RalfJung

rust-bors · 2026-03-28T17:05:09Z

📌 Commit 11c673b has been approved by tgross35,RalfJung

It is now in the queue for this repository.

…tgross35,RalfJung Merge `fabsf16/32/64/128` into `fabs::<F>` Following [a small conversation on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Float.20intrinsics/with/521501401) (and because I'd be interested in starting to contribute on Rust), I thought I'd give a try at merging the float intrinsics :) This PR just merges `fabsf16`, `fabsf32`, `fabsf64`, `fabsf128`, as it felt like an easy first target. Notes: - I'm opening the PR for one intrinsic as it's probably easier if the shift is done one intrinsic at a time, but let me know if you'd rather I do several at a time to reduce the number of PRs. - Currently this PR increases LOCs, despite being an attempt at simplifying the intrinsics/compilers. I believe this increase is a one time thing as I had to define new functions and move some things around, and hopefully future PRs/commits will reduce overall LoCs - `fabsf32` and `fabsf64` are `#[rustc_intrinsic_const_stable_indirect]`, while `fabsf16` and `fabsf128` aren't; because `f32`/`f64` expect the function to be const, the generic version must be made indirectly stable too. We'd need to check with T-lang this change is ok; the only other intrinsics where there is such a mismatch is `minnum`, `maxnum` and `copysign`. - I haven't touched libm because I'm not familiar with how it works; any guidance would be welcome!

…uwer Rollup of 7 pull requests Successful merges: - #147811 (naked functions: respect `function-sections`) - #153834 (Merge `fabsf16/32/64/128` into `fabs::<F>`) - #154043 (simd_fmin/fmax: make semantics and name consistent with scalar intrinsics) - #154494 (triagebot: add reminder for bumping CI LLVM stamp) - #153374 (Fix LegacyKeyValueFormat report from docker build: dist-x86_64) - #154320 (`trim_prefix` for paths) - #154453 (Fix ice in rustdoc of private reexport)

…tgross35,RalfJung Merge `fabsf16/32/64/128` into `fabs::<F>` Following [a small conversation on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Float.20intrinsics/with/521501401) (and because I'd be interested in starting to contribute on Rust), I thought I'd give a try at merging the float intrinsics :) This PR just merges `fabsf16`, `fabsf32`, `fabsf64`, `fabsf128`, as it felt like an easy first target. Notes: - I'm opening the PR for one intrinsic as it's probably easier if the shift is done one intrinsic at a time, but let me know if you'd rather I do several at a time to reduce the number of PRs. - Currently this PR increases LOCs, despite being an attempt at simplifying the intrinsics/compilers. I believe this increase is a one time thing as I had to define new functions and move some things around, and hopefully future PRs/commits will reduce overall LoCs - `fabsf32` and `fabsf64` are `#[rustc_intrinsic_const_stable_indirect]`, while `fabsf16` and `fabsf128` aren't; because `f32`/`f64` expect the function to be const, the generic version must be made indirectly stable too. We'd need to check with T-lang this change is ok; the only other intrinsics where there is such a mismatch is `minnum`, `maxnum` and `copysign`. - I haven't touched libm because I'm not familiar with how it works; any guidance would be welcome!

…uwer Rollup of 9 pull requests Successful merges: - #150752 (Update libc to v0.2.183) - #153380 (stabilize new RangeFrom type and iterator) - #153834 (Merge `fabsf16/32/64/128` into `fabs::<F>`) - #154043 (simd_fmin/fmax: make semantics and name consistent with scalar intrinsics) - #154494 (triagebot: add reminder for bumping CI LLVM stamp) - #153374 (Fix LegacyKeyValueFormat report from docker build: dist-x86_64) - #154320 (`trim_prefix` for paths) - #154453 (Fix ice in rustdoc of private reexport) - #154515 (Notify stdarch maintainers on changes in std_detect)

Rollup of 9 pull requests Successful merges: - #153380 (stabilize new RangeFrom type and iterator) - #153834 (Merge `fabsf16/32/64/128` into `fabs::<F>`) - #154043 (simd_fmin/fmax: make semantics and name consistent with scalar intrinsics) - #154494 (triagebot: add reminder for bumping CI LLVM stamp) - #153374 (Fix LegacyKeyValueFormat report from docker build: dist-x86_64) - #154320 (`trim_prefix` for paths) - #154453 (Fix ice in rustdoc of private reexport) - #154504 (move many tests from `structs-enums` to `structs` or `enum`) - #154515 (Notify stdarch maintainers on changes in std_detect)

Rollup merge of #153834 - N1ark:generic-float-intrinsics, r=tgross35,RalfJung Merge `fabsf16/32/64/128` into `fabs::<F>` Following [a small conversation on Zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Float.20intrinsics/with/521501401) (and because I'd be interested in starting to contribute on Rust), I thought I'd give a try at merging the float intrinsics :) This PR just merges `fabsf16`, `fabsf32`, `fabsf64`, `fabsf128`, as it felt like an easy first target. Notes: - I'm opening the PR for one intrinsic as it's probably easier if the shift is done one intrinsic at a time, but let me know if you'd rather I do several at a time to reduce the number of PRs. - Currently this PR increases LOCs, despite being an attempt at simplifying the intrinsics/compilers. I believe this increase is a one time thing as I had to define new functions and move some things around, and hopefully future PRs/commits will reduce overall LoCs - `fabsf32` and `fabsf64` are `#[rustc_intrinsic_const_stable_indirect]`, while `fabsf16` and `fabsf128` aren't; because `f32`/`f64` expect the function to be const, the generic version must be made indirectly stable too. We'd need to check with T-lang this change is ok; the only other intrinsics where there is such a mismatch is `minnum`, `maxnum` and `copysign`. - I haven't touched libm because I'm not familiar with how it works; any guidance would be welcome!

Rollup of 9 pull requests Successful merges: - rust-lang/rust#153380 (stabilize new RangeFrom type and iterator) - rust-lang/rust#153834 (Merge `fabsf16/32/64/128` into `fabs::<F>`) - rust-lang/rust#154043 (simd_fmin/fmax: make semantics and name consistent with scalar intrinsics) - rust-lang/rust#154494 (triagebot: add reminder for bumping CI LLVM stamp) - rust-lang/rust#153374 (Fix LegacyKeyValueFormat report from docker build: dist-x86_64) - rust-lang/rust#154320 (`trim_prefix` for paths) - rust-lang/rust#154453 (Fix ice in rustdoc of private reexport) - rust-lang/rust#154504 (move many tests from `structs-enums` to `structs` or `enum`) - rust-lang/rust#154515 (Notify stdarch maintainers on changes in std_detect)

rustbot assigned TaKO8Ki Mar 13, 2026

rustbot added the T-libs Relevant to the library team, which will review and decide on the PR/issue. label Mar 13, 2026

N1ark changed the title ~~Merge fabsfN into fabs::<F>~~ Merge fabsf16/32/64/128 into fabs::<F> Mar 13, 2026

rustbot assigned tgross35 and unassigned TaKO8Ki Mar 13, 2026

This comment has been minimized.

Sign in to view

scottmcm reviewed Mar 13, 2026

View reviewed changes

tgross35 reviewed Mar 13, 2026

View reviewed changes

compiler/rustc_codegen_llvm/src/intrinsic.rs Outdated Show resolved Hide resolved

tgross35 reviewed Mar 13, 2026

View reviewed changes

compiler/rustc_codegen_gcc/src/intrinsic/mod.rs Outdated Show resolved Hide resolved

This comment has been minimized.

Sign in to view

N1ark mentioned this pull request Mar 14, 2026

Cleanup handling of f128 intrinsics in GCC #153864

Closed

This comment has been minimized.

Sign in to view

N1ark force-pushed the generic-float-intrinsics branch from 69be112 to 9210d78 Compare March 14, 2026 12:50

This comment has been minimized.

Sign in to view

RalfJung reviewed Mar 15, 2026

View reviewed changes

library/core/src/intrinsics/mod.rs Outdated Show resolved Hide resolved

compiler/rustc_const_eval/src/interpret/intrinsics.rs Outdated Show resolved Hide resolved

compiler/rustc_const_eval/src/interpret/intrinsics.rs Show resolved Hide resolved

RalfJung reviewed Mar 15, 2026

View reviewed changes

RalfJung added the I-lang-nominated Nominated for discussion during a lang team meeting. label Mar 15, 2026

rust-rfcbot removed the proposed-final-comment-period Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off. label Mar 18, 2026

tgross35 added S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 22, 2026

rustbot mentioned this pull request Mar 28, 2026

Tracking issue for release notes of #153834: Merge fabsf16/32/64/128 into fabs::<F> #154509

Closed

RalfJung removed the S-waiting-on-fcp Status: PR is in FCP and is awaiting for FCP to complete. label Mar 28, 2026

rust-bors bot added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Mar 28, 2026

JonathanBrouwer mentioned this pull request Mar 28, 2026

Rollup of 7 pull requests #154514

Closed

JonathanBrouwer mentioned this pull request Mar 28, 2026

Rollup of 9 pull requests #154519

Closed

GuillaumeGomez mentioned this pull request Mar 28, 2026

Rollup of 9 pull requests #154525

Merged

rust-bors bot merged commit e6f17e4 into rust-lang:main Mar 29, 2026
11 checks passed

rustbot added this to the 1.96.0 milestone Mar 29, 2026

N1ark deleted the generic-float-intrinsics branch March 29, 2026 11:06

	/// Types with a built-in dereference operator in runtime MIR,
	/// aka references and raw pointers.
	///
	/// # Safety
	/// Must actually be such a type.
	pub unsafe trait BuiltinDeref: Sized {
	type Pointee: PointeeSized;
	}

	unsafe impl<T: PointeeSized> BuiltinDeref for &mut T {
	type Pointee = T;
	}
	unsafe impl<T: PointeeSized> BuiltinDeref for &T {
	type Pointee = T;
	}
	unsafe impl<T: PointeeSized> BuiltinDeref for *mut T {
	type Pointee = T;
	}
	unsafe impl<T: PointeeSized> BuiltinDeref for *const T {
	type Pointee = T;
	}

	pub const fn fabs<T: Copy>(x: T) -> T;
	pub const fn fabs<T: bounds::FloatPrimitive>(x: T) -> T;

Uh oh!

Conversation

N1ark commented Mar 13, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Mar 13, 2026

Uh oh!

rustbot commented Mar 13, 2026

Uh oh!

tgross35 commented Mar 13, 2026

Uh oh!

This comment has been minimized.

N1ark commented Mar 13, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

N1ark Mar 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

N1ark commented Mar 14, 2026

Uh oh!

RalfJung commented Mar 14, 2026

Uh oh!

This comment has been minimized.

N1ark commented Mar 14, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment has been minimized.

This comment has been minimized.

scottmcm commented Mar 15, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

RalfJung Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

N1ark Mar 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rust-rfcbot commented Mar 28, 2026

Uh oh!

RalfJung commented Mar 28, 2026

Uh oh!

rust-bors bot commented Mar 28, 2026

Uh oh!

RalfJung commented Mar 28, 2026

Uh oh!

rust-bors bot commented Mar 28, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

N1ark commented Mar 13, 2026 •

edited by rustbot

Loading

N1ark Mar 14, 2026 •

edited

Loading

N1ark commented Mar 14, 2026 •

edited

Loading

RalfJung Mar 15, 2026 •

edited

Loading

N1ark Mar 15, 2026 •

edited

Loading