Tracking Issue for `float_semantics` RFC 3514
traviscross opened this issue · 1 comments
This is a tracking issue for RFC 3514:
The feature gate for the issue is #![feature(float_semantics)].
About tracking issues
Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
- Accept an RFC.
- Update library documentation.
- Add documentation to the reference.
- See the instructions.
- N/A: Add formatting for new syntax to the style guide.
- See the nightly style procedure.
- Stabilize.
Unresolved Questions
- Should we be concerned that LLVM does not actually document that it uses IEEE float semantics? It does assume IEEE semantics in its own optimization passes.
- Are there any other targets with floating-point trouble?
- What exactly is the set of "extra" NaNs for all remaining targets?
- To what extend does this specification apply to platform intrinsics? On the one hand, it seems reasonable to expect platform intrinsics to have the behavior of the platform instructions. On the other hand, we implement some platform intrinsics with the portable LLVM
simdintrinsics, and those are subject to the NaN-non-determinism described above. So the current de-facto semantics of at least some platform intrinsics is that they do not match what the platform does.
Related
TODO.
cc @RalfJung @rust-lang/lang
The RFC largely documents how rustc and Miri already behave. So the main task here is to write suitable documentation -- not sure where the discussion of which NaNs can be generated would even go. Probably somewhere in the reference, but ideally mentioned in the f32/f64 type docs as well, or so?
The other main outcome of this is that can we proceed with stabilization of #57241.