DETECT_F causes an invalid FP operation

[amorison]

Describe the bug
Calling h5open_f (Fortran) leads to an invalid floating point exception. This is problematic when catching FPEs, as the application crashes when initializing HDF5.

With the following prgm.f90 program:

program prgm
    use hdf5
    implicit none
    integer :: ierr
    call h5open_f(ierr)
    if (ierr /= 0) then
        error stop "error open"
    endif
    call h5close_f(ierr)
    if (ierr /= 0) then
        error stop "error close"
    endif
    print "(a)", "all good"
end program

We have the following issue:

$ h5pfc -showme
gfortran -I/usr/include -L/usr/lib -lhdf5hl_fortran -lhdf5_hl -lhdf5_fortran -lhdf5 -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto -lsz -lz -ldl -lm -Wl,-rpath -Wl,/usr/lib

$ h5pfc prgm.f90 -ffpe-trap=invalid

$ gdb a.out
# ...
(gdb) run
# ...
Program received signal SIGFPE, Arithmetic exception.
0x00007ffff7cd5072 in H5T__init_native_float_types () at /usr/src/debug/hdf5-openmpi/hdf5-1.14.3/src/H5Tinit_float.c:531
531         DETECT_F(long double, LDOUBLE, det);

Expected behavior
No FPE should be raised when initializing HDF5.

Platform (please complete the following information)

• HDF5 version: 1.14.3
• OS and version: arch linux, up-to-date at the time of writing
• Compiler and version: gfortran 13.2.1
• Build system (e.g. CMake, Autotools) and version: NA
• Any configure options you specified: NA
• MPI library and version (parallel HDF5): NA

Additional context
We do not encounter the issue with hdf5 1.12 on other machines.

[derobins]

It's probably because you are building with -ffpe-trap=invalid. That's incompatible with our floating-point type introspection. We moved some compile-type checks to run-time checks (to make cross-compiling easier) and some of the floating-point checks can raise FPEs that are normally ignored. We'll engineer around this for 1.14.4.

[amorison]

Thanks for looking into this.

It's probably because you are building with -ffpe-trap=invalid.

Yes, the program above is definitely crashing because I'm explicitly trapping FPEs. That's on purpose: I am working on an application that does scientific computing, and using those options is very useful to track FP issues when debugging. HDF5 crashing with an FPE on initialization renders these options useless for my purposes.

[derobins]

Thanks for looking into this.

It's probably because you are building with -ffpe-trap=invalid.

Yes, the program above is definitely crashing because I'm explicitly trapping FPEs. That's on purpose: I am working on an application that does scientific computing, and using those options is very useful to track FP issues when debugging. HDF5 crashing with an FPE on initialization renders these options useless for my purposes.

I have a fix in #3837 that disables FE_INVALID exceptions while initializing the floating-point datatypes (restoring the original flags on the way out). We generate NaNs in that code as we munge bits and check to see what's happening. We're probing type behavior and not doing math per se, so I think that's a better solution than making many changes to protect against NaN.

[mjreno]

Perhaps not new information but seeing this on macOS:

ProductName: macOS
ProductVersion: 13.6
Homebrew 4.2.10
gcc: 13.2.0
netcdf-fortran: 4.6.1
netcdf: 4.9.2
hdf5: 1.14.3