7 ms·

You should be able to see the floating point exception by testing fetestexcept(FE_INVALID) (if it returns nonzero/true then you have a domain error). errno is a

You should be able to see the floating point exception by testing fetestexcept(FE_INVALID) (if it returns nonzero/true then you have a domain error). errno is also set as a side effect. (edit), for instance this gives me output of "1": #include <math.h> #include <fenv.h> #include <stdio.h> int main(void) { double a = sin(INFINITY); printf("%d\n", fetestexcept(FE_INVALID)); return 0; }

eesmith 4y ago
"1" on my FreeBSD/Intel box. "0" on my Mac/M1 box with the vendor cc but "1" with gcc-12. I think I have an outdated idea that there should be a way to have the exception trigger a SIGFPE, and that modern processors don't do that.
- jacobmartin 4y ago
  fascinating! Does vendor cc link to a different libc? I wonder if that is the problem and the docs are for glibc. And testing just now, I can't even trigger SIGFPE with division by zero (integer or float). I guess all of these exceptions are "caught" now.
  - eesmith 4y ago
    It took a while but I figured it out. Apple's cc compiles to: a.out: Mach-O 64-bit executable arm64 while my gcc-12 compiles to: a.out: Mach-O 64-bit executable x86_64 which is then emulated via Rosetta.
- light_hue_1 4y ago
  You need to enable floating point trapping. It's trivial, but it's not on by default. Although, in that case, this function would still be pure as far as Haskell is concerned. Because its output only depends on its input. Interrupts/exceptions are outside of the scope of the type system as far as an individual function goes.
- jcranmer 4y ago
  What compilers are you using, what flags are you using with those compilers? If you care about it, you need to use the appropriate flags to get a strict floating-point model. If you merely have a precise or fast floating-point model, calling fetestexception is going to result in unspecified behavior. [If you really want to be strict, the result of flags are unspecified if you don't use #pragma FENV_ACCESS ON, but gcc refuses to support FENV_ACCESS pragma, and you instead need to use command-line flags to get the same effect.] > I think I have an outdated idea that there should be a way to have the exception trigger a SIGFPE, and that modern processors don't do that. On Intel, you can clear the exception mask for the INVALID FP exception in mxcsr and get an SIGFPE whenever an operation raises INVALID [assuming, again, strict model to ensure the optimizer respects fp exceptions.] I don't know how, or if, AArch64 can enable hardware traps on floating-point exceptions.

eesmith 4y ago

"1" on my FreeBSD/Intel box. "0" on my Mac/M1 box with the vendor cc but "1" with gcc-12. I think I have an outdated idea that there should be a way to have the exception trigger a SIGFPE, and that modern processors don't do that.

jacobmartin 4y ago
fascinating! Does vendor cc link to a different libc? I wonder if that is the problem and the docs are for glibc. And testing just now, I can't even trigger SIGFPE with division by zero (integer or float). I guess all of these exceptions are "caught" now.
- eesmith 4y ago
  It took a while but I figured it out. Apple's cc compiles to: a.out: Mach-O 64-bit executable arm64 while my gcc-12 compiles to: a.out: Mach-O 64-bit executable x86_64 which is then emulated via Rosetta.
light_hue_1 4y ago
You need to enable floating point trapping. It's trivial, but it's not on by default. Although, in that case, this function would still be pure as far as Haskell is concerned. Because its output only depends on its input. Interrupts/exceptions are outside of the scope of the type system as far as an individual function goes.
jcranmer 4y ago
What compilers are you using, what flags are you using with those compilers? If you care about it, you need to use the appropriate flags to get a strict floating-point model. If you merely have a precise or fast floating-point model, calling fetestexception is going to result in unspecified behavior. [If you really want to be strict, the result of flags are unspecified if you don't use #pragma FENV_ACCESS ON, but gcc refuses to support FENV_ACCESS pragma, and you instead need to use command-line flags to get the same effect.] > I think I have an outdated idea that there should be a way to have the exception trigger a SIGFPE, and that modern processors don't do that. On Intel, you can clear the exception mask for the INVALID FP exception in mxcsr and get an SIGFPE whenever an operation raises INVALID [assuming, again, strict model to ensure the optimizer respects fp exceptions.] I don't know how, or if, AArch64 can enable hardware traps on floating-point exceptions.