On Wed, 12 Oct 2022 17:00:15 GMT, Andrew Haley <a...@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 Isn't it an illustration of a more general problem we have with native code where it can mess with FP environment at any time? We already have similar problems with MXCSR register and provide verification logic (part of `-Xcheck:jni`) to catch modifications and support conditional restoration of MXCSR register on x86_64. x86_32 validates x87 control word when `-Xcheck:jni` is enabled. Should we do something similar here instead? ------------- PR: https://git.openjdk.org/jdk/pull/10661
