Tracking Issue for core_float_math

[tgross35]

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

• Background
  • Methods moved from core to std to avoid C libm dependency Remove dependencies on libm functions from libcore. #27823
  • Discussion Tracking issue for f32 and f64 methods in libcore #50145
  • Discussion Math support in core rfcs#2505
  • Trivial methods moved to core float types: move copysign, abs, signum to libcore #131304
• Implementation:
  • Initial implementation Initial implementation of core_float_math #138087
  • Functions moved to a module core_float_math: Move functions to math module #141282
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

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

[durin42]

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]

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]

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]

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]

@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]

Filed!