Tracking Issue for `float_semantics` RFC 3514

This is a tracking issue for RFC 3514:

• https://github.com/rust-lang/rfcs/pull/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.
  • https://github.com/rust-lang/rfcs/pull/3514
• Update library documentation.
  • https://github.com/rust-lang/rust/pull/129559
• Stabilize.
  • https://github.com/rust-lang/rust/pull/128596
• Add documentation to the reference.
  • In particular, inline asm interactions still need to be documented.

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?
  • We will treat these as target-specific bugs when they show up
• What exactly is the set of "extra" NaNs for all remaining targets?
  • https://github.com/rust-lang/rust/pull/138870 covers all tier 2 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 simd intrinsics, 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

Start by reading RFC 3514 and the Rust Reference contribution instructions linked in the issue. Focus on documenting float_semantics, especially its interactions with inline assembly and the remaining unresolved questions. Done means the missing Reference documentation is added and the tracking checklist can be updated.