RFR: 8374785: Template Library: need to tag Float16.copySign as having non-deterministic result because of multiple NaNs with different sign bits

Tobias Hartmann thartmann at openjdk.org
Thu Jan 8 15:01:26 UTC 2026


On Thu, 8 Jan 2026 14:50:46 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

> This is a very similar issue as https://github.com/openjdk/jdk/pull/29033 / [JDK-8374489](https://bugs.openjdk.org/browse/JDK-8374489).
> 
> There are `NaN` encodings that have the sign bit set, and others that have it not set.
> If we now copy the sign from such a `NaN` to a numeric value (e.g. `1`), we can get `1` or `-1`.
> 
> 
> jshell> var a = Float.NaN;
> a ==> NaN
> jshell> var b = Float.intBitsToFloat(0xFFC00000);
> b ==> NaN
> jshell> Math.copySign(1f, a)
> ==> 1.0
> jshell> Math.copySign(1f, b)
> ==> -1.0
> jshell> Float16.copySign(Float16.valueOf(1f), Float16.valueOf(a))
> ==> 1.0
> jshell> Float16.copySign(Float16.valueOf(1f), Float16.valueOf(b))
> ==> -1.0
> 
> 
> Since `NaN` values of different encodings are interchangable, and we cannot know what `NaN` we get, and hence the sign bit is arbitrary, we can also not know the sign of the result of `Float16.copySign`. We have to mark it as non-deterministic and hence disable result verification.
> 
> Since this is a test-bug, I have no regression test. But I verified it manually, that with the same seed (for the ExpressionFuzzer) that fails before this change, we now succeed after the change.

Looks good to me.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29118#pullrequestreview-3639814696


More information about the hotspot-compiler-dev mailing list