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

Add support for floating point exceptions #47930

Draft
wants to merge 12 commits into
base: master
Choose a base branch
from
Draft

Add support for floating point exceptions #47930

wants to merge 12 commits into from

Conversation

simonbyrne
Copy link
Contributor

Fixes #27705.

Still more to do, just want to see if it builds

@simonbyrne
Copy link
Contributor Author

simonbyrne commented Dec 20, 2022

@c42f you expressed interest in this.

One issue is that the floating point environment is tied to a thread: for our purposes, it would probably make more sense to tie it to a task. this would require saving and restoring the floating point environment whenever we switch tasks. I assume we can do this by adding a fenv_t field to the jl_task_t struct, and calling fegetenv/fesetenv. Which functions would need the hooks?

@Keno
Copy link
Member

Keno commented Dec 20, 2022

This doesn't really make sense without hooking up the constrained fp intrinsics from the LLVM side, because otherwise LLVM will just be free to move things around and you'll get unexpected results.

@simonbyrne
Copy link
Contributor Author

I disagree: while the results might be a bit unreliable, it's still helpful for figuring out where NaNs are coming from

@simonbyrne
Copy link
Contributor Author

It's also a bit of a chicken and egg problem: we need one to motivate the other

1 similar comment
@simonbyrne
Copy link
Contributor Author

It's also a bit of a chicken and egg problem: we need one to motivate the other

@Keno
Copy link
Member

Keno commented Dec 20, 2022

You're breaking things like the compiler's nothrow modeling though, so you'll definitely get memory corruption and undefined behavior by turning this on.

@c42f
Copy link
Member

c42f commented Dec 20, 2022

breaking things like the compiler's nothrow modeling

So, this would be similar to the way that force throwing InterruptException breaks the compiler's assumptions and can lead to unexpected results? Though we have that escape hatch because it's so darn useful because it mostly "kind of works" for interactive use.

Regarding InexactFloatingPointException I can see you'd add that for completeness. Though I found when I played with this ages ago, it was almost impossible to enable. For example, entering the compiler as part of a user's generic call can result in inexact FP operations as part of compilation happening in the same task. Which then easily result in an exception.

@gbaraldi
Copy link
Member

What if you make a macro that wraps a function call, or something, that from julia itself inspects the floating point exception flags, and in the macro you throw an exception?

@brenhinkeller brenhinkeller added the domain:error handling Handling of exceptions by Julia or the user label Dec 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain:error handling Handling of exceptions by Julia or the user
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Trap floating point exceptions
5 participants