Skip to content

Commit

Permalink
mention the problem with FreeBSD
Browse files Browse the repository at this point in the history
  • Loading branch information
RalfJung committed Oct 20, 2023
1 parent 8d46e0b commit 4363023
Showing 1 changed file with 6 additions and 2 deletions.
8 changes: 6 additions & 2 deletions text/0000-float-semantics.md
Original file line number Diff line number Diff line change
Expand Up @@ -128,8 +128,12 @@ Furthermore, observing the floating-point exception state yields entirely unspec
# Drawbacks
[drawbacks]: #drawbacks

This RFC is too restrictive for some targets and too vague for some users: it is too vague since NaN signs are still left completely non-deterministic, which is not actually the case on hardware. It is also too restrictive as shown by the following subsection.

- This RFC is too restrictive for some targets and too vague for some users: it is too vague since NaN signs are still left completely non-deterministic, which is not actually the case on hardware.
It is also too restrictive as shown by the following subsection.
- It [looks](https://reviews.freebsd.org/D33599) like some targets, such FreeBSD, leave the floating-point environment in signal handlers in an unspecified state.
Rust (just like C without `#pragma STD FENV_ACCESS`) cannot currently be used to write signal handlers on such targets.
There is little we can do here with the current state of LLVM; and even once LLVM provides the necessary features, these signal handlers will need annotations in the code that tell the compiler about the non-default floating point state.
Those targets chose to use a semantics that is hard to support well in a highly optimized language, and there's not much we can do to paper over such target quirks.

### Target-specific problems

Expand Down

0 comments on commit 4363023

Please sign in to comment.