Created attachment 15189 [details]
test case foo.c

According to ISO C 23 § 7.6.4.5, fesetexceptflag is supposed to set floating-point exception flags without raising a trap.
  "Like fesetexcept, this function does not raise floating-point exceptions, but only sets the state of the flags."

That's not how glibc's implementation does it on 32-bit x86, 64-bit x86_64, and powerpc/powerpc64/powerpc64le.

The powerpc/powerpc64/powerpc64le case is already being handled in https://sourceware.org/bugzilla/show_bug.cgi?id=30988 . Therefore here let me concentrate on x86 and x86_64.

How to reproduce:
1. Compile the attached program foo.c.
Compiling for 64-bit mode on x86_64 hosts, or for 32-bit mode on i386 hosts:
$ gcc -Wall foo.c -lm
Compiling for 32-bit mode on x86_64 hosts:
$ i686-linux-gnu-gcc -Wall foo.c -lm
or
$ gcc -m32 -Wall foo.c -lm

2. Run it.
$ ./a.out
Floating point exception


I think it is a hardware limitation that on i386 and x86_64 CPUs, setting
a floating-point exception flag in the 387 unit triggers a trap, when
traps are enabled for the particular exception. But setting a
floating-point exception flag in the SSE unit does not have this
problem, cf. glibc/sysdeps/x86_64/fpu/fesetexcept.c.

Therefore I would expect the fesetexceptflag() function to operate correctly
when the hardware has an SSE unit (determined e.g. like in
sysdeps/i386/fpu/ftestexcept.c).
And only in the case where the CPU has only the 387 unit, I would expect
the fesetexceptflag() function to return a non-zero value (as error indicator)
and not modify the 387 floating-point control register, when this is the
only way to avoid a trap.