On Tue, 18 Oct 2022 07:43:13 GMT, Florian Weimer <fwei...@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
