Skip to content

Commit 4363023

Browse files
committed
mention the problem with FreeBSD
1 parent 8d46e0b commit 4363023

File tree

1 file changed

+6
-2
lines changed

1 file changed

+6
-2
lines changed

text/0000-float-semantics.md

+6-2
Original file line numberDiff line numberDiff line change
@@ -128,8 +128,12 @@ Furthermore, observing the floating-point exception state yields entirely unspec
128128
# Drawbacks
129129
[drawbacks]: #drawbacks
130130

131-
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.
132-
131+
- 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.
132+
It is also too restrictive as shown by the following subsection.
133+
- It [looks](https://reviews.freebsd.org/D33599) like some targets, such FreeBSD, leave the floating-point environment in signal handlers in an unspecified state.
134+
Rust (just like C without `#pragma STD FENV_ACCESS`) cannot currently be used to write signal handlers on such targets.
135+
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.
136+
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.
133137

134138
### Target-specific problems
135139

0 commit comments

Comments
 (0)