Tracking Issue for `float_semantics` RFC 3514

[traviscross]

This is a tracking issue for RFC 3514:

• add float semantics RFC rfcs#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.
  • add float semantics RFC rfcs#3514
• Update library documentation.
  • float types: document NaN bit pattern guarantees #129559
• Stabilize.
  • stabilize const_fn_floating_point_arithmetic #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?
  • Add target-specific NaN payloads for the missing tier 2 targets #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

[RalfJung]

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.