-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add round_ties_even
to f32
and f64
#95317
Conversation
Some changes occured to rustc_codegen_gcc cc @antoyo |
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @yaahc (or someone else) soon. Please see the contribution instructions for more information. |
d769b92
to
ad51ecd
Compare
This comment was marked as outdated.
This comment was marked as outdated.
ad51ecd
to
3a23dfc
Compare
This comment has been minimized.
This comment has been minimized.
3a23dfc
to
3ed85dd
Compare
Assuming that the symbol names are correct for the cranelift and gcc codegen backends, the compiler changes here look simple and correct. so I'd say r=me for the compiler side. I'll let @yaahc speak for the libs side. |
Don't think this should block merging this PR, but just to add my opinion to the mix, I've basically always seen this called |
I'm reassigning this PR because I'm taking a break from the review rotation for a little while. Thank you for your patience. r? rust-lang/libs-api |
Given that we have Other inspiration from wikipedia:
|
We can leave the bikeshed for later, after adding this as unstable but before stabilization. Can you open a tracking issue for this feature? Please include the open question about the name of the function, and the open question about whether this should be the default behaviour of |
Tracking issue opened. |
This comment was marked as outdated.
This comment was marked as outdated.
3ed85dd
to
d2c6c6e
Compare
Hello, is the status (waiting for review) of this PR correct? Any pending comments from |
Looks like this has a r=me for the compiler changes, and a "seems reasonable" from libs-api, so I think this is just waiting on a tracking issue (#95317 (comment)) to be mergeable, with bikesheds to happen on that tracking issue. So I've marked it S-author. |
The job Click to see the possible cause of the failure (guessed by this bot)
|
Looks spurious. |
⌛ Testing commit 371d570 with merge 9f10e462f6256a1db9f38ef3bc46f917dd753c95... |
💔 Test failed - checks-actions |
This failure doesn't look related either |
☀️ Test successful - checks-actions |
Finished benchmarking commit (0a3b557): comparison URL. Overall result: ✅ improvements - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. |
The job Click to see the possible cause of the failure (guessed by this bot)
|
Why do the tests here use |
I just cargo-culted the |
…=pnkfelix,m-ou-se,scottmcm Add `round_ties_even` to `f32` and `f64` Tracking issue: rust-lang#96710 Redux of rust-lang#82273. See also rust-lang#55107 Adds a new method, `round_ties_even`, to `f32` and `f64`, that rounds the float to the nearest integer , rounding halfway cases to the number with an even least significant bit. Uses the `roundeven` LLVM intrinsic to do this. Of the five IEEE 754 rounding modes, this is the only one that doesn't already have a round-to-integer function exposed by Rust (others are `round`, `floor`, `ceil`, and `trunc`). Ties-to-even is also the rounding mode used for int-to-float and float-to-float `as` casts, as well as float arithmentic operations. So not having an explicit rounding method for it seems like an oversight. Bikeshed: this PR currently uses `round_ties_even` for the name of the method. But maybe `round_ties_to_even` is better, or `round_even`, or `round_to_even`?
…=pnkfelix,m-ou-se,scottmcm Add `round_ties_even` to `f32` and `f64` Tracking issue: rust-lang#96710 Redux of rust-lang#82273. See also rust-lang#55107 Adds a new method, `round_ties_even`, to `f32` and `f64`, that rounds the float to the nearest integer , rounding halfway cases to the number with an even least significant bit. Uses the `roundeven` LLVM intrinsic to do this. Of the five IEEE 754 rounding modes, this is the only one that doesn't already have a round-to-integer function exposed by Rust (others are `round`, `floor`, `ceil`, and `trunc`). Ties-to-even is also the rounding mode used for int-to-float and float-to-float `as` casts, as well as float arithmentic operations. So not having an explicit rounding method for it seems like an oversight. Bikeshed: this PR currently uses `round_ties_even` for the name of the method. But maybe `round_ties_to_even` is better, or `round_even`, or `round_to_even`?
Tracking issue: #96710
Redux of #82273. See also #55107
Adds a new method,
round_ties_even
, tof32
andf64
, that rounds the float to the nearest integer , rounding halfway cases to the number with an even least significant bit. Uses theroundeven
LLVM intrinsic to do this.Of the five IEEE 754 rounding modes, this is the only one that doesn't already have a round-to-integer function exposed by Rust (others are
round
,floor
,ceil
, andtrunc
). Ties-to-even is also the rounding mode used for int-to-float and float-to-floatas
casts, as well as float arithmentic operations. So not having an explicit rounding method for it seems like an oversight.Bikeshed: this PR currently uses
round_ties_even
for the name of the method. But mayberound_ties_to_even
is better, orround_even
, orround_to_even
?