ADDITIONAL SYSTEM INFORMATION :
- Operating system: Linux
- Compiler/toolchain: GCC 9.5
- Source commit: 24fe61ea13610d2f5d22f1b6696b871eb0505379 (tag: 17.0.19-internal+0, branch: master)
- Build type: release
- Build environment: Linux, compiled from source with GCC 9.5
- Also happens on 17.0.17+10, released version


A DESCRIPTION OF THE PROBLEM :
A minimal Java program compares the raw bit patterns of Float.NaN and the result of a floating-point expression that should also produce a NaN: Float.floatToRawIntBits(Float.NaN) vs Float.floatToRawIntBits(varFloat % 0 + Float.NaN). When run with different HotSpot execution modes, the program returns different results:
- With -Xcomp, the comparison reports the two NaNs as having different bit patterns.
- With -Xmixed and -Xint, the comparison reports equal bit patterns.

This suggests a discrepancy in NaN canonicalization or optimization between compiled (-Xcomp) and interpreted/mixed modes. While IEEE 754 allows multiple NaN payloads, the inconsistency across modes for the same code path on the same JVM build appears unexpected and may indicate a JIT optimization or code generation issue around NaN handling.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1) Save the following source as Test.java.
2) Run the program with each of the following commands:
- java -Xcomp Test.java
- java -Xmixed Test.java
- java -Xint Test.java

---------- BEGIN SOURCE ----------

public class Test {

    public static int Func() {
        float varFloat = 0.5f;
        if (
            !(
                Float.floatToRawIntBits(Float.NaN)
                ==
                Float.floatToRawIntBits(varFloat % 0 + Float.NaN)
            )
        ) {
            return 20;
        }

        return 10;
    }

    public static void main(String[] strArr) {
        
        System.out.println("FuncRet: " + Func());
    }
}

---------- END SOURCE ----------

FREQUENCY :
ALWAYS