Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FPE proposal #201

Draft
wants to merge 3 commits into
base: develop
Choose a base branch
from
Draft

Conversation

donnaaboise
Copy link
Member

@donnaaboise donnaaboise commented Mar 17, 2022

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

@scottaiton scottaiton changed the base branch from master to develop March 17, 2022 16:40
@donnaaboise
Copy link
Member Author

donnaaboise commented Mar 24, 2022

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.


/* This doesn't appear to actually do anything */
fclaw2d_vtable_t *vt = fclaw2d_vt();
signal(SIGFPE, vt->fpe_signal_handler);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also this signal never fires on Apple Silicon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants