Add special compilation flags for Interpreter in GCC13 and newer

[r30shah]

In certain JDK versions when interpreter code is compiled with GCC13, we observed sub-optimal performance. When using the GCC13 for compiling VM, use these special compilation flags for interpreter code that provides on par or better performance compared to GCC11.

[pshipton]

@keithc-ca is there a better way to do this that will work for gcc 14+, or actually gcc 13+?

[keithc-ca]

If we want to test for gcc 13+, we may need to resort to checking that it's not 1-12 (like line 183, but with filter):

ifeq (,$(filter $(GCC_MAJOR_VERSION),1 2 3 4 5 6 7 8 9 10 11 12)) # 13+

[keithc-ca]

Actually, I think line 183 is broken; e.g. gcc 10+ are mishandled there.

[keithc-ca]

I thought we might use $(intcmp), but it seems to require make version 4.4.1.

[keithc-ca]

Please correct the commit message and this pull request title/description to reflect that the boundary is gcc 13+ (not 14+).

[keithc-ca]

Please squash.

[r30shah]

Squashed commits.

[keithc-ca]

Jenkins test sanity amac,plinux,xlinux,zlinux jdk25

[r30shah]

Not sure if this test suppose to be excluded or not for JDK25 - seems like the failing test was added to JDK25 last week (ibmruntimes/openj9-openjdk-jdk25@be3a705)

STDERR:
14:43:57  java.lang.UnsatisfiedLinkError: jdk/test/whitebox/WhiteBox.registerNatives()V
14:43:57  	at jdk.test.whitebox.WhiteBox.<clinit>(WhiteBox.java:59)
14:43:57  	at OSRWithManyLocals.<clinit>(OSRWithManyLocals.java:45)
14:43:57  	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized0(Native Method)
14:43:57  	at java.base/jdk.internal.misc.Unsafe.ensureClassInitialized(Unsafe.java:1455)
14:43:57  	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.ensureClassInitialized(MethodHandleAccessorFactory.java:341)
14:43:57  	at java.base/jdk.internal.reflect.MethodHandleAccessorFactory.newMethodAccessor(MethodHandleAccessorFactory.java:72)
14:43:57  	at java.base/jdk.internal.reflect.ReflectionFactory.newMethodAccessor(ReflectionFactory.java:119)
14:43:57  	at java.base/java.lang.reflect.Method.acquireMethodAccessor(Method.java:717)
14:43:57  	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
14:43:57  	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
14:43:57  	at java.base/java.lang.Thread.run(Thread.java:1485)

I do see other OSRTest excluded in [1], @pshipton / @keithc-ca is this one suppose to be excluded given we do not support WhiteBox ?

[1]. https://github.com/adoptium/aqa-tests/blob/49e6ebb2c4560ab8d9e9a5f4850c8e4079e52099/openjdk/excludes/ProblemList_openjdk25-openj9.txt#L156

[keithc-ca]

Yes, I think OSRWithManyLocals should be excluded like it is for jdk26+. I created adoptium/aqa-tests#6877 to address that.

The other failure I see with java/lang/Thread/virtual/CustomScheduler.java is tracked via #22110.