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 f16 and f128 float types #116909

Open
42 of 84 tasks
traviscross opened this issue Oct 18, 2023 · 30 comments
Open
42 of 84 tasks

Tracking Issue for f16 and f128 float types #116909

traviscross opened this issue Oct 18, 2023 · 30 comments
Assignees
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-f16_and_f128 `#![feature(f16)]`, `#![feature(f128)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-lang Relevant to the language team, which will review and decide on the PR/issue.

Comments

@traviscross
Copy link
Contributor

traviscross commented Oct 18, 2023

This is a tracking issue for the RFC 3453 (rust-lang/rfcs#3453).

The feature gate for the issue is #![feature(f16_and_f128)].

From the RFC:

This RFC proposes adding new IEEE-compliant floating point types f16 and f128 into the core language and standard library. We will provide a soft float implementation for all targets, and use hardware support where possible.

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

  • Do any new target features need to be marked as "forbidden" since they affect ABI? The logic here looks like that may be the case.

Implementation history

Note that unimplemented!("f16_f128") and // FIXME(f16_f128) is being used where relevant, to make the todo list easily greppable.

Nice to have changes:

@traviscross traviscross added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Oct 18, 2023
@traviscross

This comment has been minimized.

@rustbot rustbot added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Oct 18, 2023
@traviscross

This comment has been minimized.

@rustbot rustbot added the B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. label Oct 19, 2023
@tgross35

This comment was marked as outdated.

@gorentbarak

This comment has been minimized.

@gorentbarak

This comment has been minimized.

@gorentbarak

This comment has been minimized.

@rustbot rustbot added the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Oct 27, 2023
@gorentbarak

This comment has been minimized.

@rustbot

This comment has been minimized.

@gorentbarak

This comment has been minimized.

@rustbot rustbot added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 27, 2023
@lqd

This comment has been minimized.

@lqd lqd removed the I-prioritize Issue: Indicates that prioritization has been requested for this issue. label Oct 27, 2023
@traviscross traviscross added the F-f16_and_f128 `#![feature(f16)]`, `#![feature(f128)]` label Nov 4, 2023
@tgross35
Copy link
Contributor

tgross35 commented Dec 9, 2023

A blocking issue should be added: ensure C compatibility with ABI-cafe or similar

#114607 (comment)

@tgross35
Copy link
Contributor

tgross35 commented Feb 28, 2024

Implementation steps (could somebody link this in the top post?):

(massive todo list moved to the top post)

@rustbot claim

@scottmcm
Copy link
Member

It appears that today f128 doesn't trigger the incomplete_features lint: https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=9d8a3698d5d506fc960bde270e9a1a54

It might be a good idea to do that for now, to avoid people making threads like https://users.rust-lang.org/t/display-for-f128/114405?u=scottmcm

bors added a commit to rust-lang-ci/rust that referenced this issue Jul 30, 2024
…indows-abi, r=<try>

Match LLVM ABI in `extern "C"` functions for `f128` on Windows

As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work.

I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`.

Tracking issue: rust-lang#116909

try-job: x86_64-msvc
try-job: x86_64-mingw
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jul 30, 2024
…-windows-abi, r=tgross35

Match LLVM ABI in `extern "C"` functions for `f128` on Windows

As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work.

I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`.

Tracking issue: rust-lang#116909

try-job: x86_64-msvc
try-job: x86_64-mingw
tgross35 added a commit to tgross35/rust that referenced this issue Jul 31, 2024
…-windows-abi, r=tgross35

Match LLVM ABI in `extern "C"` functions for `f128` on Windows

As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work.

I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`.

Tracking issue: rust-lang#116909

try-job: x86_64-msvc
try-job: x86_64-mingw
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jul 31, 2024
…-windows-abi, r=tgross35

Match LLVM ABI in `extern "C"` functions for `f128` on Windows

As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work.

I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`.

Tracking issue: rust-lang#116909

try-job: x86_64-msvc
try-job: x86_64-mingw
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jul 31, 2024
…-windows-abi, r=tgross35

Match LLVM ABI in `extern "C"` functions for `f128` on Windows

As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work.

I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`.

Tracking issue: rust-lang#116909

try-job: x86_64-msvc
try-job: x86_64-mingw
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Jul 31, 2024
Rollup merge of rust-lang#128388 - beetrees:f16-f128-slightly-improve-windows-abi, r=tgross35

Match LLVM ABI in `extern "C"` functions for `f128` on Windows

As MSVC doesn't support `_Float128`, x86-64 Windows doesn't have a defined ABI for `f128`. Currently, Rust will pass and return `f128` indirectly for `extern "C"` functions. This is inconsistent with LLVM, which passes and returns `f128` in XMM registers, meaning that e.g. the ABI of `extern "C"` compiler builtins won't match. This PR fixes this discrepancy by making the x86-64 Windows `extern "C"` ABI pass `f128` directly through to LLVM, so that Rust will follow whatever LLVM does. This still leaves the difference between LLVM and GCC (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115054) but this PR is still an improvement as at least Rust is now consistent with it's primary codegen backend and compiler builtins from `compiler-builtins` will now work.

I've also fixed the x86-64 Windows `has_reliable_f16` match arm in `std` `build.rs` to refer to the correct target, and added an equivalent match arm to `has_reliable_f128` as the LLVM-GCC ABI difference affects both `f16` and `f128`.

Tracking issue: rust-lang#116909

try-job: x86_64-msvc
try-job: x86_64-mingw
@beetrees
Copy link
Contributor

beetrees commented Aug 2, 2024

Tier 3 powerpc64-ibm-aix doesn't currently support f128 arguments: llvm/llvm-project#101545

tgross35 added a commit to tgross35/rust that referenced this issue Aug 17, 2024
…=compiler-errors

Fix `is_val_statically_known` for floats

The LLVM intrinsic name for floats differs from the LLVM type name, so handle them explicitly. Also adds support for `f16` and `f128`.

`f16`/`f128` tracking issue: rust-lang#116909
tgross35 added a commit to tgross35/rust that referenced this issue Aug 17, 2024
…=compiler-errors

Fix `is_val_statically_known` for floats

The LLVM intrinsic name for floats differs from the LLVM type name, so handle them explicitly. Also adds support for `f16` and `f128`.

`f16`/`f128` tracking issue: rust-lang#116909
tgross35 added a commit to tgross35/rust that referenced this issue Aug 17, 2024
…=compiler-errors

Fix `is_val_statically_known` for floats

The LLVM intrinsic name for floats differs from the LLVM type name, so handle them explicitly. Also adds support for `f16` and `f128`.

`f16`/`f128` tracking issue: rust-lang#116909
jieyouxu added a commit to jieyouxu/rust that referenced this issue Aug 18, 2024
…=compiler-errors

Fix `is_val_statically_known` for floats

The LLVM intrinsic name for floats differs from the LLVM type name, so handle them explicitly. Also adds support for `f16` and `f128`.

`f16`/`f128` tracking issue: rust-lang#116909
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Aug 18, 2024
Rollup merge of rust-lang#129173 - beetrees:statically-known-float, r=compiler-errors

Fix `is_val_statically_known` for floats

The LLVM intrinsic name for floats differs from the LLVM type name, so handle them explicitly. Also adds support for `f16` and `f128`.

`f16`/`f128` tracking issue: rust-lang#116909
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 27, 2024
…, r=<try>

Add `f16` and `f128` inline ASM support for `aarch64`

Adds `f16` and `f128` inline ASM support for `aarch64`. SIMD vector types are taken from [the ARM intrinsics list](https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:`@navigationhierarchiesreturnbasetype=[float]&f:@navigationhierarchieselementbitsize=[16]&f:@navigationhierarchiesarchitectures=[A64]).` Based on the work of `@lengrongfu` in rust-lang#127043.

Relevant issue: rust-lang#125398
Tracking issue: rust-lang#116909

`@rustbot` label +F-f16_and_f128

try-job: aarch64-gnu
try-job: aarch64-apple
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 27, 2024
…, r=<try>

Add `f16` and `f128` inline ASM support for `aarch64`

Adds `f16` and `f128` inline ASM support for `aarch64`. SIMD vector types are taken from [the ARM intrinsics list](https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:`@navigationhierarchiesreturnbasetype=[float]&f:@navigationhierarchieselementbitsize=[16]&f:@navigationhierarchiesarchitectures=[A64]).` Based on the work of `@lengrongfu` in rust-lang#127043.

Relevant issue: rust-lang#125398
Tracking issue: rust-lang#116909

`@rustbot` label +F-f16_and_f128

try-job: aarch64-gnu
try-job: aarch64-apple
tgross35 added a commit to tgross35/rust that referenced this issue Aug 27, 2024
…64, r=Amanieu

Add `f16` and `f128` inline ASM support for `aarch64`

Adds `f16` and `f128` inline ASM support for `aarch64`. SIMD vector types are taken from [the ARM intrinsics list](https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:`@navigationhierarchiesreturnbasetype=[float]&f:@navigationhierarchieselementbitsize=[16]&f:@navigationhierarchiesarchitectures=[A64]).` Based on the work of `@lengrongfu` in rust-lang#127043.

Relevant issue: rust-lang#125398
Tracking issue: rust-lang#116909

`@rustbot` label +F-f16_and_f128

try-job: aarch64-gnu
try-job: aarch64-apple
rust-timer added a commit to rust-lang-ci/rust that referenced this issue Aug 27, 2024
Rollup merge of rust-lang#129536 - beetrees:f16-f128-inline-asm-aarch64, r=Amanieu

Add `f16` and `f128` inline ASM support for `aarch64`

Adds `f16` and `f128` inline ASM support for `aarch64`. SIMD vector types are taken from [the ARM intrinsics list](https://developer.arm.com/architectures/instruction-sets/intrinsics/#f:`@navigationhierarchiesreturnbasetype=[float]&f:@navigationhierarchieselementbitsize=[16]&f:@navigationhierarchiesarchitectures=[A64]).` Based on the work of `@lengrongfu` in rust-lang#127043.

Relevant issue: rust-lang#125398
Tracking issue: rust-lang#116909

`@rustbot` label +F-f16_and_f128

try-job: aarch64-gnu
try-job: aarch64-apple
@beetrees
Copy link
Contributor

llvm/llvm-project#104915: f16 abs and neg quieten signalling NaNs on targets where f16 is not natively supported.

@86maid

This comment has been minimized.

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-f16_and_f128 `#![feature(f16)]`, `#![feature(f128)]` T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. 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

10 participants