FPE proposal

[donnaaboise]

This snippet tests a DYI approach to handling exceptions for the M1 :

• It relies on fenv.h and signal.h
• See routine enable_floating_point_exceptions().
• This would replace fp_exception_glibc_extension.{c,h}
• This should only be needed for Mac M1s, where it seems that FPEs are not handled, so the build system would have to detect whether feeenableexcept is available.
• This snippet runs as a standalone example. See the README.txt

Ideas for code taken from

https://developer.apple.com/forums/thread/689159 and https://stackoverflow.com/questions/69059981/how-to-trap-floating-point-exceptions-on-m1-macs

[donnaaboise]

Maybe the easiest thing to do is just include a file fclaw_exceptions.{c,h} but don't include it in the compiled code. If a user wants exception handling and doesn't have it on their system, we can suggest they include this in their example. That way, we aren't responsible for any build issues that might come up, or any dubious behavior this DYI exception handling might create.

Only drawback to this approach is that we do have option --trap-fpe which should then either be disabled, or only do something if "FCLAW_HAVE_FEENABLEEXCEPT` is true (is this easy to check in the build system)? If the user doesn't have this, we could virtualize an exception handler and then let the user define their own (e.g. the one proposed here).

My proposal is, then :

• Provide a DYI exception handler routine (e.g. fclaw_enable_exceptions in core ForestClaw, but don't actually compile it in the library.

• Use FCLAW_HAVE_ENABLEEXCEPT' (set by build system) and status of option--trap-fpe` to decide whether to turn on exception handling.

if (--trap_fpe)
{
#if FCLAW_HAVE_FEENABLEEXCEPT
   /* Call system version */
    feenableexcept(INVALID | OVERFLOW | UNDERFLOW | ...)
#else
   /* Call user-defined virtualized version (e.g. the one proposed here) */
   fclaw_vt->feenableexcept()
#endif
}

If the user hasn't overridden the virtual feenableexept(), alert them that they do not appear to have feenableexcept on their system and should consider our DYI option, at their own risk, of course.