Skip to content
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.

Sign up for GitHub

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

Jump to bottom

powf for NaN returns 1 #60468

Closed
CodeSandwich opened this issue May 2, 2019 · 7 comments
Closed

powf for NaN returns 1 #60468

CodeSandwich opened this issue May 2, 2019 · 7 comments
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.

Comments

@CodeSandwich
Copy link

The powf for floating point numbers seems to have optimization: when base is 1, always return 1. This optimization does not check if exponent is a number, so

1f32.powf(std::f32::NAN) == 1.

This behavior is same for debug and release modes, f32 and f64. playground
@nikic nikic added the A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. label May 2, 2019
@nikic
Copy link
Contributor

nikic commented May 2, 2019

Relevant code in LLVM: https://github.com/llvm-mirror/llvm/blob/b79c73bd103edafbaff703c7230fcf1fe4e3b920/lib/Transforms/Utils/SimplifyLibCalls.cpp#L1421

@nagisa
Copy link
Member

nagisa commented May 2, 2019 •
edited
Loading

The contract for the powf function allows requires this behaviour (cited from linux’s man-pages for powf(3)):

  Except as specified below, if x or y is a NaN, the result is a NaN.
  If x is +1, the result is 1.0 (even if y is a NaN).
  If y is 0, the result is 1.0 (even if x is a NaN).

@nagisa
Copy link
Member

nagisa commented May 2, 2019 •
edited
Loading

Interestingly, that does not correspond to any IEEE-754 pow* operation, but it does properly follow the POSIX and [C99] standards, so closing as not-a-bug.

@nagisa nagisa closed this as completed May 2, 2019
@jonas-schievink
Copy link
Contributor

This could use additional documentation though, the docs for powf are very bare-bones right now

@nagisa
Copy link
Member

nagisa commented May 2, 2019

Copying the documentation for most functions from the POSIX standard would make sense for me, but that probably wants a separate issue specifically about that.

@qnighy
Copy link
Contributor

qnighy commented May 4, 2019

Interestingly, that does not correspond to any IEEE-754 pow* operation, but...

It seems to comply with IEEE754 pow behavior described in IEEE754-2008 p.44 (§9.2.1 Special values):

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=7a8b40ddf93beb95fdc19932762f4ee3

@jimblandy jimblandy mentioned this issue Oct 31, 2021
Open
@Fnll Fnll mentioned this issue Jul 11, 2024
Merged
@magic-akari magic-akari mentioned this issue Jul 12, 2024
Merged
kdy1 pushed a commit to swc-project/swc that referenced this issue Jul 12, 2024
@Fnll @magic-akari
fix(es/minifier): Fix compress pow NaN (#9210)
2b361e6 
**Description:**

`f64::powf` for `NaN` returns 1 instead of `NaN`, see
rust-lang/rust#60468. We should handle that.

**Related issue:**

 - Closes #9193

---------

Co-authored-by: magic-akari <[email protected]>
@magic-akari magic-akari mentioned this issue Jul 12, 2024
Merged
@hkBst
Copy link
Contributor

hkBst commented Jan 24, 2025

@qnighy your sample seems to be missing f64::NAN.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@qnighy @nikic @nagisa @jonas-schievink @hkBst @CodeSandwich