Skip to content

Tracking Issue for core_float_math #137578

Open
@tgross35

Description

@tgross35
Contributor

Feature gate: #![feature(core_float_math)]

This is a tracking issue for floating point math operations in core.

Public API

The following API will be made available in core:

impl {f16, f32, f64, f128} {
    pub fn floor(self) -> Self;
    pub fn ceil(self) -> Self;
    pub fn round(self) -> Self;
    pub fn round_ties_even(self) -> Self;
    pub fn trunc(self) -> Self;
    pub fn fract(self) -> Self;
    pub fn mul_add(self, a: Self, b: Self) -> Self;
    pub fn div_euclid(self, rhs: f128) -> Self;
    pub fn rem_euclid(self, rhs: f128) -> Self;
    pub fn powi(self, n: i32) -> Self;
    pub fn sqrt(self) -> Self;
    // Not yet added to f128
    pub fn cbrt(self) -> Self;
    // Deprecated, but there isn't any reason not to move it
    pub fn abs_sub(self, other: Self) -> Self;
}

More will be added in the future. The blocker for others is the quality of our libm implementations (I am working on improving this).

For f32 and f64, it isn't easily possible to have the methods unstable in core but stable in std, so standalone functions are used for the feature gate (e.g. core::f32::sqrt). For stabilization these will be changed to inherent and the duplicates in std removed.

Steps / History

Unresolved Questions

  • None yet.

Footnotes

  1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html

Activity

added
C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.
on Feb 25, 2025
added a commit that references this issue on Mar 6, 2025

Auto merge of rust-lang#138087 - tgross35:core-float-math, r=<try>

added a commit that references this issue on Mar 6, 2025

Auto merge of rust-lang#138087 - tgross35:core-float-math, r=<try>

added a commit that references this issue on Mar 6, 2025

Auto merge of rust-lang#138087 - tgross35:core-float-math, r=<try>

added 3 commits that reference this issue on Mar 6, 2025

Auto merge of rust-lang#138087 - tgross35:core-float-math, r=<try>

Auto merge of rust-lang#138087 - tgross35:core-float-math, r=<try>

Auto merge of rust-lang#138087 - tgross35:core-float-math, r=<try>

34 remaining items

added a commit that references this issue on May 23, 2025

Rollup merge of rust-lang#141282 - DJMcNab:core-float-math-math, r=tg…

durin42

durin42 commented on Jun 5, 2025

@durin42
Contributor

A question related to this work: I'm chasing some odd behavior (binary size increases) in our monorepo built with bazel that looks related to the libm functions being exposed, and as a practice we want to avoid "using Rust transitively secretly replaces your uses of libm with Rust's bundled functions" - but that's what we observe now. I can reproduce this even using make to build a C program and link it with a staticlib crate - the exposed functions (eg ceilf) clobber the references to libm, switching the implementation used by the C calls as well.

We already unconditionally pass -lm on our linker invocations anyway, so we'll probably just build compiler-builtins without the libm functionality internally. Would you be open to a patch to make that a semi-supported option?

(I'm happy to discuss more on zulip or something, just figured I'd start here.)

durin42

durin42 commented on Jun 5, 2025

@durin42
Contributor

Oh, a related Chromium issue: https://issues.chromium.org/issues/419258012#comment5 - they fixed it with ordering of linker args, but it still seems not-great that people are getting surprised.

tgross35

tgross35 commented on Jun 5, 2025

@tgross35
ContributorAuthor

I believe the problem there is that statically linked weak symbols win out against any dynamic symbols, which means our libm wins out. Would it be possible to inject an object file that provides strong math symbols but forwards to dlopened libm.so? Or some linker scripting / object file editing, though that's less nice. (Part of the reason the symbols are weak is to allow overriding with specific implementations.)

If that doesn't work then I think a feature would be possible, but that's tough to get right considering inconsistencies across which platforms make which symbols available - which the build system will know about but we don't (mostly relevant for f128).

Cc @Amanieu for any thoughts here.

Amanieu

Amanieu commented on Jun 5, 2025

@Amanieu
Member

So I previously thought that statically linked weak symbols always override strong dynamic symbols, but this may not actually be the case. It could simply be that libcompiler_builtins.rlib appears before -lm in the linker command line, which results in the linker picking the first one that it sees, with no regards as to whether it is a strong or weak symbol.

We could go back to preferring the system symbols by simply ensuring that compiler_builtins is placed after any system libraries in the linker command line.

tgross35

tgross35 commented on Jun 5, 2025

@tgross35
ContributorAuthor

@durin42 would you mind opening a new issue for discussing linkage separately from the rest of core_float_math? If it's just a link order thing then that might give us a way to work around the lack of string.h symbols on no_std as well.

durin42

durin42 commented on Jun 6, 2025

@durin42
Contributor

Filed!

sagudev

sagudev commented on Jun 25, 2025

@sagudev
Contributor

Both euclid methods are implemented on top of existing core functionality, so they are not really blocked like others on intrinsics.

tgross35

tgross35 commented on Jun 25, 2025

@tgross35
ContributorAuthor

The euclid methods need to be reworked and we will likely move them into our libm (see #107904 and discussion at #134145)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @durin42@Amanieu@tgross35@sagudev

        Issue actions

          Tracking Issue for `core_float_math` · Issue #137578 · rust-lang/rust