Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for float_semantics RFC 3514 #128288

Open
2 of 8 tasks
traviscross opened this issue Jul 27, 2024 · 3 comments
Open
2 of 8 tasks

Tracking Issue for float_semantics RFC 3514 #128288

traviscross opened this issue Jul 27, 2024 · 3 comments
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-float_semantics `#![feature(float_semantics)]` T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@traviscross
Copy link
Contributor

traviscross commented Jul 27, 2024

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

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 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

@traviscross traviscross added T-lang Relevant to the language team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. F-float_semantics `#![feature(float_semantics)]` labels Jul 27, 2024
@RalfJung
Copy link
Member

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.

matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 24, 2024
…rithmetic, r=nnethercote

stabilize const_fn_floating_point_arithmetic

Part of rust-lang#128288
Fixes rust-lang#57241

The existing test `tests/ui/consts/const_let_eq_float.rs`  ([link](https://github.com/RalfJung/rust/blob/const_fn_floating_point_arithmetic/tests/ui/consts/const_let_eq_float.rs)) covers the basics, and also Miri has extensive tests covering the interpreter's float machinery. Also, that machinery can already be used on stable inside `const`/`static` initializers, just not inside `const fn`.

This was explicitly called out in rust-lang/rfcs#3514 so in a sense t-lang just recently already FCP'd this, but let's hear from them whether they want another FCP for the stabilization here or whether that was covered by the FCP for the RFC.
Cc `@rust-lang/lang`

### Open items

- [x] Update the Reference: rust-lang/reference#1566
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 24, 2024
…rithmetic, r=nnethercote

stabilize const_fn_floating_point_arithmetic

Part of rust-lang#128288
Fixes rust-lang#57241

The existing test `tests/ui/consts/const_let_eq_float.rs`  ([link](https://github.com/RalfJung/rust/blob/const_fn_floating_point_arithmetic/tests/ui/consts/const_let_eq_float.rs)) covers the basics, and also Miri has extensive tests covering the interpreter's float machinery. Also, that machinery can already be used on stable inside `const`/`static` initializers, just not inside `const fn`.

This was explicitly called out in rust-lang/rfcs#3514 so in a sense t-lang just recently already FCP'd this, but let's hear from them whether they want another FCP for the stabilization here or whether that was covered by the FCP for the RFC.
Cc ``@rust-lang/lang``

### Open items

- [x] Update the Reference: rust-lang/reference#1566
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Aug 25, 2024
Rollup merge of rust-lang#128596 - RalfJung:const_fn_floating_point_arithmetic, r=nnethercote

stabilize const_fn_floating_point_arithmetic

Part of rust-lang#128288
Fixes rust-lang#57241

The existing test `tests/ui/consts/const_let_eq_float.rs`  ([link](https://github.com/RalfJung/rust/blob/const_fn_floating_point_arithmetic/tests/ui/consts/const_let_eq_float.rs)) covers the basics, and also Miri has extensive tests covering the interpreter's float machinery. Also, that machinery can already be used on stable inside `const`/`static` initializers, just not inside `const fn`.

This was explicitly called out in rust-lang/rfcs#3514 so in a sense t-lang just recently already FCP'd this, but let's hear from them whether they want another FCP for the stabilization here or whether that was covered by the FCP for the RFC.
Cc ``@rust-lang/lang``

### Open items

- [x] Update the Reference: rust-lang/reference#1566
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Aug 26, 2024
…, r=nnethercote

stabilize const_fn_floating_point_arithmetic

Part of rust-lang/rust#128288
Fixes rust-lang/rust#57241

The existing test `tests/ui/consts/const_let_eq_float.rs`  ([link](https://github.com/RalfJung/rust/blob/const_fn_floating_point_arithmetic/tests/ui/consts/const_let_eq_float.rs)) covers the basics, and also Miri has extensive tests covering the interpreter's float machinery. Also, that machinery can already be used on stable inside `const`/`static` initializers, just not inside `const fn`.

This was explicitly called out in rust-lang/rfcs#3514 so in a sense t-lang just recently already FCP'd this, but let's hear from them whether they want another FCP for the stabilization here or whether that was covered by the FCP for the RFC.
Cc ``@rust-lang/lang``

### Open items

- [x] Update the Reference: rust-lang/reference#1566
workingjubilee added a commit to workingjubilee/rustc that referenced this issue Aug 27, 2024
…omcc

float types: document NaN bit pattern guarantees

Part of rust-lang#128288: document the guarantees we make for NaN bit patterns.

Cc `@tgross35`
tgross35 added a commit to tgross35/rust that referenced this issue Aug 27, 2024
…omcc

float types: document NaN bit pattern guarantees

Part of rust-lang#128288: document the guarantees we make for NaN bit patterns.

Cc ``@tgross35``
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Aug 27, 2024
Rollup merge of rust-lang#129559 - RalfJung:float-nan-semantics, r=thomcc

float types: document NaN bit pattern guarantees

Part of rust-lang#128288: document the guarantees we make for NaN bit patterns.

Cc ``@tgross35``
github-actions bot pushed a commit to rust-lang/miri that referenced this issue Aug 28, 2024
float types: document NaN bit pattern guarantees

Part of rust-lang/rust#128288: document the guarantees we make for NaN bit patterns.

Cc ``@tgross35``
@RalfJung
Copy link
Member

RalfJung commented Oct 5, 2024

With #129559 having landed, is there anything else left to do here?

@RalfJung
Copy link
Member

As of llvm/llvm-project#102140, LLVM now also properly documents the guarantees that we promise to our users -- just in time for the release. :D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. F-float_semantics `#![feature(float_semantics)]` T-lang Relevant to the language team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

2 participants