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

So here's a thought:

Reading and writing floating-point control flags can be expensive because they're serializing operations. However, we can discover whether the processor has been put into an "odd" rounding mode with just a few floating-point instructions, so we can do:


if (epsilon + epsilon == 0) {
      rtn = fesetenv(&default_fenv)
    }


which ends up as


	movsd  xmm1,QWORD PTR [epsilon]
	pxor   xmm4,xmm4
	addsd  xmm1,xmm1
	ucomisd xmm0,xmm4
	jnp    ...



We'd need a bit more fiddling to detect changes of rounding mode as well, if we wanted to do that.

That might well be chap enough that we could do it on JNI calls. Do you think it would be worth my while doing some timings?

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

PR: https://git.openjdk.org/jdk/pull/10661