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

[Andrew Haley]

On Tue, 18 Oct 2022 07:43:13 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

>> 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
>
> src/hotspot/os/linux/os_linux.cpp line 1759:
> 
>> 1757:   assert(rtn == 0, "fegetnv must succeed");
>> 1758:   void * result = ::dlopen(filename, RTLD_LAZY);
>> 1759:   rtn = fesetenv(&curr_fenv);
> 
> `fesetenv` in glibc does not unconditionally restore the old FPU control bits, only the non-reserved bits. (The mask is 0xf3f, which seems to cover everything in use today.)  It seems unlikely that more bits are going to be defined in the future. But using `fesetenv` to essentially guard against undefined behavior after the fact is a bit awkward.
> 
> MXSCR is passed through unconditionally.

Mmm, but `fesetenv` is the only portable thing we have (AFAIK). An alternative to using `fesetenv` everywhere would be to use `fesetenv` in generic code and override it in a per-backend way.

> test/hotspot/jtreg/compiler/floatingpoint/libfast-math.c line 24:
> 
>> 22:  */
>> 23: 
>> 24: // This file is intentionally left blank.
> 
> This test will silently break (no longer test what's intended) once we change GCC not to link with `crtfastmath.o` for `-shared`. Maybe you should link with `crtfastmath.o` explicitly if it exists, or change the floating point control word directly in an ELF constructor.

Perhaps so, yes.

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

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