RFR: 8295159: DSO created with -ffast-math breaks Java floating-point arithmetic [v7]

[Andrew Haley]

On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> A bug in GCC causes shared libraries linked with -ffast-math to disable denormal arithmetic. This breaks Java's floating-point semantics.
>> 
>> The bug is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55522
>> 
>> One solution is to save and restore the floating-point control word around System.loadLibrary(). This isn't perfect, because some shared library might load another shared library at runtime, but it's a lot better than what we do now. 
>> 
>> However, this fix is not complete. `dlopen()` is called from many places in the JDK. I guess the best thing to do is find and wrap them all. I'd like to hear people's opinions.
>
> Andrew Haley has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8295159: DSO created with -ffast-math breaks Java floating-point arithmetic

This is a stripped-down, less risky, and simplified patch, in order to get something done.

I removed x32 handling because it have turned out to be disproportionately fiddly. The `mxcsr` register we need to access is not a part of the `fenv` structure, so x32 needs special-case handling. This handling turns out to be problematic because HotSpot on GCC is compiled with low x32 CPU version that doesn't support the builtins or assembly instructions that we need to access `mxcsr`. I don't want to change HotSpot's default x32 CPU version, because that will affect code generation in unknown ways. Given that x32 is obsolescent, I dropped it.

In addition, I dropped the proposed warning at safepoints if the handling of denormal floating-point changes. It's fiddly and has potential compatibility issues, and may have performance impact. It's not needed to fix 8295159.

Reopened for review, in a simpler form that doesn't raise any compatibility issues.

I'm seeing one automated test failure on Linux x86, which I don't understand because I've excluded that test for generic-i586. If anyone understands this, please shout up.

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

PR Comment: https://git.openjdk.org/jdk/pull/10661#issuecomment-1743421995
PR Comment: https://git.openjdk.org/jdk/pull/10661#issuecomment-1757707730