Bug ID: JDK-8295159 DSO created with -ffast-math breaks Java floating-point arithmetic

Versions (Unresolved/Resolved/Fixed)

The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.

JDK 22
22 b23Fixed

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.

Created https://bugs.openjdk.org/browse/JDK-8319708 8319708: Assertion 'fsetenv didn't work' in jdk tier4 tests after 8295159 on Linux aarch64 RHEL9.3 Probably it would make sense to add some tracing and/or UL output in case the IEEE check fails ? Also it might make sense to check IEEE conformance already before fegetenv - we might run into cases where the environment is already non-conformant when fegetenv is called ? Also libs for example loaded directly by dlopen from jdk C code are not covered currently, might be another argument to wrap those and load them with HS os::dll_load ?
08-11-2023
Hi [~aph] we run now into assertions on our RHEL 9.2 Linux aarch test machine : # # Internal Error ( /openjdk/linuxaarch64/jdk-dev/src/hotspot/os/linux/os_linux.cpp:1850), pid=2548990, tid=2549049 # assert(IEEE_subnormal_handling_OK()) failed: fsetenv didn't work Some of those asserts can be seen in the jdk tier4 jtreg tests, e.g. javax/sound/sampled/DataLine/DataLine_ArrayIndexOutOfBounds.java . For some reason we do not see the assertion on SLES 15 . And also not on other OS/CPU platforms . Is it an issue with RHEL 9.2 ?
07-11-2023
Changeset: df599dbb Author: Andrew Haley <aph@openjdk.org> Date: 2023-11-04 09:17:11 +0000 URL: https://git.openjdk.org/jdk/commit/df599dbb9b0f0ee96d1ec767ac8821f164ab075d
04-11-2023
Hotspot/runtime mackes sense. I'm not sure what "is handled by the Runtime team" means for me.
03-10-2023
Moving to hotspot/runtime for bug triage purposes. Also, usually library support is handled by the Runtime team.
11-10-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10661 Date: 2022-10-11 16:02:41 +0000
11-10-2022

Relates :	JDK-6487931 - JVM reports EXCEPTION_FLT_STACK_CHECK when calling a Java method through JNI
Relates :	JDK-6550813 - Crash because of FPU control word being modified by native code (win32)
Relates :	JDK-8319927 - Log that IEEE rounding mode was corrupted by loading a library
Relates :	JDK-8319708 - Assertion 'fsetenv didn't work' in jdk tier4 tests after 8295159 on Linux aarch64 RHEL9.3
Relates :	JDK-8321017 - Record in JFR that IEEE rounding mode was corrupted by loading a library
Relates :	JDK-8317810 - DSO created with -ffast-math breaks Java floating-point arithmetic