Open
Description
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
tostd
to avoid Clibm
dependency Remove dependencies on libm functions from libcore. #27823 - 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 tomath
module #141282
Final comment period (FCP)1Stabilization PR
Unresolved Questions
- None yet.
Footnotes
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
Initial implementation of `core_float_math`
Initial implementation of `core_float_math`
core_float_math
#138087Initial implementation of `core_float_math`
Auto merge of rust-lang#138087 - tgross35:core-float-math, r=<try>
Initial implementation of `core_float_math`
Auto merge of rust-lang#138087 - tgross35:core-float-math, r=<try>
Initial implementation of `core_float_math`
Auto merge of rust-lang#138087 - tgross35:core-float-math, r=<try>
Initial implementation of `core_float_math`
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
Rollup merge of rust-lang#141282 - DJMcNab:core-float-math-math, r=tg…
core
#133908durin42 commentedon Jun 5, 2025
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 astaticlib
crate - the exposed functions (egceilf
) 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 commentedon Jun 5, 2025
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 commentedon Jun 5, 2025
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
dlopen
edlibm.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 commentedon Jun 5, 2025
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 commentedon Jun 5, 2025
@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 onno_std
as well.durin42 commentedon Jun 6, 2025
Filed!
sagudev commentedon Jun 25, 2025
Both euclid methods are implemented on top of existing core functionality, so they are not really blocked like others on intrinsics.
tgross35 commentedon Jun 25, 2025
The euclid methods need to be reworked and we will likely move them into our libm (see #107904 and discussion at #134145)