Skip to content

Add #[cfg(target_has_unstable_float = "...")] #866

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

Open
1 of 3 tasks
tgross35 opened this issue Apr 24, 2025 · 3 comments · May be fixed by rust-lang/rust#140323
Open
1 of 3 tasks

Add #[cfg(target_has_unstable_float = "...")] #866

tgross35 opened this issue Apr 24, 2025 · 3 comments · May be fixed by rust-lang/rust#140323
Labels
final-comment-period The FCP has started, most (if not all) team members are in agreement major-change A proposal to make a major change to rustc T-compiler Add this label so rfcbot knows to poll the compiler team

Comments

@tgross35
Copy link

Background

Support for f16 and f128 is pretty varied across targets (e.g. aarch64 is well supported, arm64ec has zero support), backends (LLVM and GCC support the types with different levels of bugs/crashes, Cranelift does not currently have them enabled), and backend versions (newer versions support more). We can introduce new API without concern because the compiler is automatically inlining relevant functions to prevent codegen, but getting maximum test coverage is problematic.

Ideally we would be testing on every target+backend+version possible, but it is difficult to find a greatest common denominator across all the variety. The current solution is config in std's build.rs https://github.com/rust-lang/rust/blob/c02a4f0852e6665cf3df3867982021383f5615df/library/std/build.rs#L84-L186 which is duplicated in compiler-builtins and libm, but that is very LLVM-specific and can't reflect things that get fixed in newer LLVM versions.

Proposal

Add a target_has_unstable_float option similar to target_has_atomic that will let us query a few different things:

#![feature(target_has_unstable_float)]
#![cfg(target_has_unstable_float = "f16")] // non-broken basic f16 support
#![cfg(target_has_unstable_float = "f16-math")] // math functions work
#![cfg(target_has_unstable_float = "f128")]
#![cfg(target_has_unstable_float = "f128-math")]

The result come from the codegen backends.

This isn't expected to ever stabilize, it's just a way for us to test as much as possible while support is still ramping up.

Mentors or Reviewers

I can implement this.

Process

The main points of the Major Change Process are as follows:

  • File an issue describing the proposal.
  • A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

@tgross35 tgross35 added major-change A proposal to make a major change to rustc T-compiler Add this label so rfcbot knows to poll the compiler team labels Apr 24, 2025
@rustbot
Copy link
Collaborator

rustbot commented Apr 24, 2025

Important

This issue is not meant to be used for technical discussion. There is a Zulip stream for that.
Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

Concerns or objections can formally be registered here by adding a comment.

@rfcbot concern reason-for-concern
<description of the concern>

Concerns can be lifted with:

@rfcbot resolve reason-for-concern

See documentation at https://forge.rust-lang.org

cc @rust-lang/compiler

@rustbot rustbot added the to-announce Announce this issue on triage meeting label Apr 24, 2025
@jieyouxu
Copy link
Member

@rustbot second

@rustbot rustbot added the final-comment-period The FCP has started, most (if not all) team members are in agreement label Apr 24, 2025
@Noratrieb
Copy link
Member

i don't think this needs an MCP, feel free to just merge it without waiting

@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Apr 24, 2025
tgross35 added a commit to tgross35/rust that referenced this issue Apr 26, 2025
Support for `f16` and `f128` is varied across targets, backends, and
backend versions. Eventually we would like to reach a point where all
backends support these approximately equally, but until then we have to
work around some of these nuances of support being observable.

Introduce the `target_has_reliable_f16_f128` configuration option, gated
behind `cfg_target_has_reliable_f16_f128`, as an indicator for whether
or not the backend supports these types to a point that they can and
should be tested. The configuration mostly follows the logic used by
`target_feature`, and similarly takes a value:

    #[cfg(target_has_reliable_f16_f128 = "f16")]

Accepted values are:

* `f16`
* `f16-math`
* `f128`
* `f128-math`

`f16` and `f128` indicate that basic arithmetic for the type works
correctly. The `-math` versions indicate that anything relying on `libm`
works correctly, since sometimes this hits a separate class of codegen
bugs.

These options match configuration set by the build script at [1]. The
logic for LLVM support is duplicated as-is from the same script. There
are a few possible updates that will come as a follow up.

The config introduced here is not intended to ever become stable, it is
only intended to replace the build scripts for `std` tests and in
`compiler-builtins` that don't have any way to set configuration based
on the codegen backend.

MCP: rust-lang/compiler-team#866
Closes: rust-lang/compiler-team#866

[1]: https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/library/std/build.rs#L84-L186
tgross35 added a commit to tgross35/rust that referenced this issue Apr 26, 2025
Support for `f16` and `f128` is varied across targets, backends, and
backend versions. Eventually we would like to reach a point where all
backends support these approximately equally, but until then we have to
work around some of these nuances of support being observable.

Introduce the `target_has_reliable_f16_f128` configuration option, gated
behind `cfg_target_has_reliable_f16_f128`, as an indicator for whether
or not the backend supports these types to a point that they can and
should be tested. The configuration mostly follows the logic used by
`target_feature`, and similarly takes a value:

    #[cfg(target_has_reliable_f16_f128 = "f16")]

Accepted values are:

* `f16`
* `f16-math`
* `f128`
* `f128-math`

`f16` and `f128` indicate that basic arithmetic for the type works
correctly. The `-math` versions indicate that anything relying on `libm`
works correctly, since sometimes this hits a separate class of codegen
bugs.

These options match configuration set by the build script at [1]. The
logic for LLVM support is duplicated as-is from the same script. There
are a few possible updates that will come as a follow up.

The config introduced here is not intended to ever become stable, it is
only intended to replace the build scripts for `std` tests and in
`compiler-builtins` that don't have any way to set configuration based
on the codegen backend.

MCP: rust-lang/compiler-team#866
Closes: rust-lang/compiler-team#866

[1]: https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/library/std/build.rs#L84-L186
bors added a commit to rust-lang-ci/rust that referenced this issue Apr 26, 2025
Implement the internal feature `cfg_target_has_reliable_f16_f128`

Support for `f16` and `f128` is varied across targets, backends, and backend versions. Eventually we would like to reach a point where all backends support these approximately equally, but until then we have to work around some of these nuances of support being observable.

Introduce the `target_has_reliable_f16_f128` configuration option, gated behind `cfg_target_has_reliable_f16_f128`, as an indicator for whether or not the backend supports these types to a point that they can and should be tested. The configuration mostly follows the logic used by `target_feature`, and similarly takes a value:

    #[cfg(target_has_reliable_f16_f128 = "f16")]

Accepted values are:

* `f16`
* `f16-math`
* `f128`
* `f128-math`

`f16` and `f128` indicate that basic arithmetic for the type works correctly. The `-math` versions indicate that anything relying on `libm` works correctly, since sometimes this hits a separate class of codegen bugs.

These options match configuration set by the build script at [1]. The logic for LLVM support is duplicated as-is from the same script. There are a few possible updates that will come as a follow up.

The config introduced here is not intended to ever become stable, it is only intended to replace the build scripts for `std` tests and in `compiler-builtins` that don't have any way to set configuration based on the codegen backend.

MCP: rust-lang/compiler-team#866
Closes: rust-lang/compiler-team#866

[1]: https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/library/std/build.rs#L84-L186

---

The second commit makes use of this config to replace `cfg_{f16,f128}{,_math}` in `library/`.

try-job: aarch64-gnu
try-job: i686-msvc-1
try-job: test-various
try-job: x86_64-gnu
try-job: x86_64-msvc-ext2
tgross35 added a commit to tgross35/rust that referenced this issue Apr 26, 2025
Support for `f16` and `f128` is varied across targets, backends, and
backend versions. Eventually we would like to reach a point where all
backends support these approximately equally, but until then we have to
work around some of these nuances of support being observable.

Introduce the `target_has_reliable_f16_f128` configuration option, gated
behind `cfg_target_has_reliable_f16_f128`, as an indicator for whether
or not the backend supports these types to a point that they can and
should be tested. The configuration mostly follows the logic used by
`target_feature`, and similarly takes a value:

    #[cfg(target_has_reliable_f16_f128 = "f16")]

Accepted values are:

* `f16`
* `f16-math`
* `f128`
* `f128-math`

`f16` and `f128` indicate that basic arithmetic for the type works
correctly. The `-math` versions indicate that anything relying on `libm`
works correctly, since sometimes this hits a separate class of codegen
bugs.

These options match configuration set by the build script at [1]. The
logic for LLVM support is duplicated as-is from the same script. There
are a few possible updates that will come as a follow up.

The config introduced here is not intended to ever become stable, it is
only intended to replace the build scripts for `std` tests and in
`compiler-builtins` that don't have any way to set configuration based
on the codegen backend.

MCP: rust-lang/compiler-team#866
Closes: rust-lang/compiler-team#866

[1]: https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/library/std/build.rs#L84-L186
tgross35 added a commit to tgross35/rust that referenced this issue Apr 26, 2025
Support for `f16` and `f128` is varied across targets, backends, and
backend versions. Eventually we would like to reach a point where all
backends support these approximately equally, but until then we have to
work around some of these nuances of support being observable.

Introduce the `cfg_target_has_reliable_f16_f128` internal feature, which
provides the following new configuration gates:

* `cfg(target_has_reliable_f16)`
* `cfg(target_has_reliable_f16_math)`
* `cfg(target_has_reliable_f128)`
* `cfg(target_has_reliable_f128_math)`

`reliable_f16` and `reliable_f128` indicate that basic arithmetic for
the type works correctly. The `_math` versions indicate that anything
relying on `libm` works correctly, since sometimes this hits a separate
class of codegen bugs.

These options match configuration set by the build script at [1]. The
logic for LLVM support is duplicated as-is from the same script. There
are a few possible updates that will come as a follow up.

The config introduced here is not planned to ever become stable, it is
only intended to replace the build scripts for `std` tests and
`compiler-builtins` that don't have any way to configure based on the
codegen backend.

MCP: rust-lang/compiler-team#866
Closes: rust-lang/compiler-team#866

[1]: https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/library/std/build.rs#L84-L186
tgross35 added a commit to tgross35/rust that referenced this issue Apr 26, 2025
Support for `f16` and `f128` is varied across targets, backends, and
backend versions. Eventually we would like to reach a point where all
backends support these approximately equally, but until then we have to
work around some of these nuances of support being observable.

Introduce the `cfg_target_has_reliable_f16_f128` internal feature, which
provides the following new configuration gates:

* `cfg(target_has_reliable_f16)`
* `cfg(target_has_reliable_f16_math)`
* `cfg(target_has_reliable_f128)`
* `cfg(target_has_reliable_f128_math)`

`reliable_f16` and `reliable_f128` indicate that basic arithmetic for
the type works correctly. The `_math` versions indicate that anything
relying on `libm` works correctly, since sometimes this hits a separate
class of codegen bugs.

These options match configuration set by the build script at [1]. The
logic for LLVM support is duplicated as-is from the same script. There
are a few possible updates that will come as a follow up.

The config introduced here is not planned to ever become stable, it is
only intended to replace the build scripts for `std` tests and
`compiler-builtins` that don't have any way to configure based on the
codegen backend.

MCP: rust-lang/compiler-team#866
Closes: rust-lang/compiler-team#866

[1]: https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/library/std/build.rs#L84-L186
tgross35 added a commit to tgross35/rust that referenced this issue Apr 27, 2025
Support for `f16` and `f128` is varied across targets, backends, and
backend versions. Eventually we would like to reach a point where all
backends support these approximately equally, but until then we have to
work around some of these nuances of support being observable.

Introduce the `cfg_target_has_reliable_f16_f128` internal feature, which
provides the following new configuration gates:

* `cfg(target_has_reliable_f16)`
* `cfg(target_has_reliable_f16_math)`
* `cfg(target_has_reliable_f128)`
* `cfg(target_has_reliable_f128_math)`

`reliable_f16` and `reliable_f128` indicate that basic arithmetic for
the type works correctly. The `_math` versions indicate that anything
relying on `libm` works correctly, since sometimes this hits a separate
class of codegen bugs.

These options match configuration set by the build script at [1]. The
logic for LLVM support is duplicated as-is from the same script. There
are a few possible updates that will come as a follow up.

The config introduced here is not planned to ever become stable, it is
only intended to replace the build scripts for `std` tests and
`compiler-builtins` that don't have any way to configure based on the
codegen backend.

MCP: rust-lang/compiler-team#866
Closes: rust-lang/compiler-team#866

[1]: https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/library/std/build.rs#L84-L186
tgross35 added a commit to tgross35/rust that referenced this issue Apr 27, 2025
Support for `f16` and `f128` is varied across targets, backends, and
backend versions. Eventually we would like to reach a point where all
backends support these approximately equally, but until then we have to
work around some of these nuances of support being observable.

Introduce the `cfg_target_has_reliable_f16_f128` internal feature, which
provides the following new configuration gates:

* `cfg(target_has_reliable_f16)`
* `cfg(target_has_reliable_f16_math)`
* `cfg(target_has_reliable_f128)`
* `cfg(target_has_reliable_f128_math)`

`reliable_f16` and `reliable_f128` indicate that basic arithmetic for
the type works correctly. The `_math` versions indicate that anything
relying on `libm` works correctly, since sometimes this hits a separate
class of codegen bugs.

These options match configuration set by the build script at [1]. The
logic for LLVM support is duplicated as-is from the same script. There
are a few possible updates that will come as a follow up.

The config introduced here is not planned to ever become stable, it is
only intended to replace the build scripts for `std` tests and
`compiler-builtins` that don't have any way to configure based on the
codegen backend.

MCP: rust-lang/compiler-team#866
Closes: rust-lang/compiler-team#866

[1]: https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/library/std/build.rs#L84-L186
tgross35 added a commit to tgross35/rust that referenced this issue Apr 27, 2025
Support for `f16` and `f128` is varied across targets, backends, and
backend versions. Eventually we would like to reach a point where all
backends support these approximately equally, but until then we have to
work around some of these nuances of support being observable.

Introduce the `cfg_target_has_reliable_f16_f128` internal feature, which
provides the following new configuration gates:

* `cfg(target_has_reliable_f16)`
* `cfg(target_has_reliable_f16_math)`
* `cfg(target_has_reliable_f128)`
* `cfg(target_has_reliable_f128_math)`

`reliable_f16` and `reliable_f128` indicate that basic arithmetic for
the type works correctly. The `_math` versions indicate that anything
relying on `libm` works correctly, since sometimes this hits a separate
class of codegen bugs.

These options match configuration set by the build script at [1]. The
logic for LLVM support is duplicated as-is from the same script. There
are a few possible updates that will come as a follow up.

The config introduced here is not planned to ever become stable, it is
only intended to replace the build scripts for `std` tests and
`compiler-builtins` that don't have any way to configure based on the
codegen backend.

MCP: rust-lang/compiler-team#866
Closes: rust-lang/compiler-team#866

[1]: https://github.com/rust-lang/rust/blob/555e1d0386f024a8359645c3217f4b3eae9be042/library/std/build.rs#L84-L186
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
final-comment-period The FCP has started, most (if not all) team members are in agreement major-change A proposal to make a major change to rustc T-compiler Add this label so rfcbot knows to poll the compiler team
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants