Hi, please consider the following changes: This is a fix for the `StrictMath.pow()` method, which corrects its numerical behavior in certain cases.
It was recently reported by [Gladman et al](https://members.loria.fr/PZimmermann/papers/accuracy.pdf) that the `pow()` method in the original FDLIBM returns with error of 636 ulps in certain cases. `StrictMath.pow()` is a direct port of FDLIBM `pow()`. It turned out that `ivln2` constant split into high and low parts (`ivln2_h` and `ivln2_l` respectively) in the original method is not sufficient to compute `u = ivln2_h * t` exactly in certain cases, namely when the span of non-zero bits in `t` is wide. By the default split, the high part `ivln2_h` contains 24 high bits of `ivln2`, and by changing the split so that `ivln2_h` contains only 21 bits of `ivln2` we ensure that `u = ivln2_h * t` is computed exactly in all cases when pow(x,y) does no overflow. New testcases added. --------- - [x] I confirm that I make this contribution in accordance with the [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). ------------- Commit messages: - 8326547: Added a comment about the pow bug fix to StrictMath. - 8326547: Fixed the pow() bug. Added tests and comments. Changes: https://git.openjdk.org/jdk/pull/30984/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=30984&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326547 Stats: 44 lines in 5 files changed: 38 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/30984.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/30984/head:pull/30984 PR: https://git.openjdk.org/jdk/pull/30984
