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

[Emanuel Peter]

On Mon, 12 Jan 2026 09:41:32 GMT, Quan Anh Mai <qamai 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.
>
> Marked as reviewed by qamai (Committer).

@merykitty @TobiHartmann Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/29118#issuecomment-3738052994