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 On 10/26/22 03:24, John Rose wrote: > Now I'm curious: What's this magic code? Does it multiply a couple of > well-chosen constants and test for zero? static const double unity = 0x1.0p-1020; static const volatile double thresh = 0x0.0000000000003p-1022; if (unity + (thresh) == unity || -unity - (thresh) == -unity) { ... fix the badness Here, thresh is the smallest denormal number that has two bits set. Unity is a number such that, when thresh is added it it, must be rounded according to the mode. These two tests detect the rounding mode in use. If denormals are turned off (i.e. denormals-are-zero) it looks like round- to-zero mode is in use. This is essentially the same test that Joe Darcy posted earlier in this thread, but scaled to make thresh so small that it is denormal. > I said "I guess" because I'm not clear on (a) the benefit of adding that > nanosecond (other than preserving denorms against a rare system fault), nor > on (b) what are the remaining faults not checked for, but which a more > expensive MSR spill/restore would fix. If someone turned on flush-denormal-results-to-zero but didn't also turn on denormals-are-zero I guess we'd miss that. Otherwise it doesn't matter. I'd like the JVM to be protected against the GCC -ffast-math bug because the resulting JVM fault silently produces incorrect results. We can do that with a test after each dlopen(). But that doesn't work in a robust way: if we call some native code that itself dlopen()s a library compiled with -ffast-math we still lose. Hmm, I guess I could scale the operands a bit more to detect that too... What fun! ------------- PR: https://git.openjdk.org/jdk/pull/10661
