Tracking issue: 32bit x86 targets without SSE2 have unsound floating point behavior #114479

RalfJung · 2023-08-04T18:46:10Z

On x86 (32bit) targets that cannot use SSE2 instructions (this includes the tier 1 i686 targets with flags that disable SSE2 support, such as -C target-cpu=pentium), floating-point operation can return results that are rounded in different ways than they should, and results can be "inconsistent": depending on whether const-propagation happened, the same computation can produce different results, leading to a program that seemingly contradicts itself. This is caused by using x87 instructions to perform floating-point arithmetic, which do not accurately implement IEEE floating-point semantics (not with the right precision, anyway). The test tests/ui/numbers-arithmetic/issue-105626.rs has an example of such a problem.

Worse, LLVM can use x87 register to store values it thinks are floats, which resets the signaling bit and thus alters the value -- leading to miscompilations.

This is an LLVM bug: rustc is generating LLVM IR with the intended semantics, but LLVM does not compile that code in the way that the LLVM LangRef describes. This is a known and long-standing problem, and very hard to fix. The affected targets are so niche these days that that is nobody's priority. The purpose of this issue mostly is to document its existence and to give it a URL that can be referenced.

Some ideas that have been floated for fixing this problem:

We could emit different instruction sequences for floating-point operations that emulate the expected rounding behavior using x87 instructions. This will likely require changes deep in LLVM's x86 backend. This is what Java does.
We could use softfloats.
~~We could set the FPU control register to 64bit precision for Rust programs, and require other code to set the register in that way before calling into a Rust library.~~ this does not work

Related issues:

Wrong optimization: instability of x87 floating-point results leads to nonsense llvm/llvm-project#44218: basically the same bug on the LLVM side, and pointing out the potential for soundness issues
Tracking issue: 32bit x86 targets lose float NaN payload in return values #115567: that's a different problem, also affecting x86-32 but unrelated to what happens when an FP operation is executed; it is about the behavior of NaN bits as they get returned from a function

Prior issues:

Comparing to infinity is buggy on x87 #72327

The text was updated successfully, but these errors were encountered:

DemiMarie · 2023-08-04T20:25:19Z

Can we just drop support for x86 without SSE2 or fall back to software floating point?

RalfJung · 2023-08-04T21:02:27Z

Can we just drop support for x86 without SSE2

We currently have the following targets in that category:

i586-pc-windows-msvc
i586-unknown-linux-gnu
i586-unknown-linux-musl

They are all tier 2. I assume people added them for a reason so I doubt they will be happy about having them dropped. Not sure to what extent floating point support is needed on those targets, but I don't think we have a concept of "target without FP support".

or fall back to software floating point?

In theory of course we can, not sure if that would be any easier than following the Java approach.

programmerjake · 2023-08-04T21:49:04Z

or fall back to software floating point?

In theory of course we can, not sure if that would be any easier than following the Java approach.

it should be much easier since LLVM already supports that, unlike the Java scheme (afaik)

https://gcc.godbolt.org/z/14WdnKhhP

RalfJung · 2023-08-14T14:16:53Z

FWIW f32 on x86-32-noSSE should actually be fine, since double-rounding is okay as long as the precision gap between the two modes is big enough. Only f64 has a problem since it is "too close" to the 80bit-precision of the x87 FPU.

On another note, we even have code in the standard library that temporarily alters the x87 FPU control word to ensure exact 64bit precision...

RalfJung · 2023-09-05T12:47:33Z

I wonder if there's something that could be done about the fact that this also affects tier 1 targets with custom (stable) flags such as -C target-cpu=pentium. Do we still want to consider that a tier 1 target in itself? Is there a way that we can just reject flags that would disable SSE2 support, and tell people to use a different target instead?

DemiMarie · 2023-09-05T14:20:49Z

@RalfJung What about forcing non-SSE2 targets to software floating point? That must be supported anyway because of kernel code.

RalfJung · 2023-09-05T14:59:07Z

Yeah that's an option listed above, since you already proposed it before. I have no idea how feasible it is. People are very concerned about the softfloat support for f16/f128 leading to code bloat and whatnot, so the same concerns would likely also apply here.

AFAIK the kernel code just doesn't use floats, I don't think they have softfloats?

…bilee add notes about non-compliant FP behavior on 32bit x86 targets Based on ton of prior discussion (see all the issues linked from rust-lang/unsafe-code-guidelines#237), the consensus seems to be that these targets are simply cursed and we cannot implement the desired semantics for them. I hope I properly understood what exactly the extent of the curse is here, let's make sure people with more in-depth FP knowledge take a close look! In particular for the tier 3 targets I have no clue which target is affected by which particular variant of the x86_32 FP curse. I assumed that `i686` meant SSE is used so the "floating point return value" is the only problem, while everything lower (`i586`, `i386`) meant x87 is used. I opened rust-lang#114479 to concisely describe and track the issue. Cc `@workingjubilee` `@thomcc` `@chorman0773` `@rust-lang/opsem` Fixes rust-lang#73288 Fixes rust-lang#72327

Rollup merge of rust-lang#113053 - RalfJung:x86_32-float, r=workingjubilee add notes about non-compliant FP behavior on 32bit x86 targets Based on ton of prior discussion (see all the issues linked from rust-lang/unsafe-code-guidelines#237), the consensus seems to be that these targets are simply cursed and we cannot implement the desired semantics for them. I hope I properly understood what exactly the extent of the curse is here, let's make sure people with more in-depth FP knowledge take a close look! In particular for the tier 3 targets I have no clue which target is affected by which particular variant of the x86_32 FP curse. I assumed that `i686` meant SSE is used so the "floating point return value" is the only problem, while everything lower (`i586`, `i386`) meant x87 is used. I opened rust-lang#114479 to concisely describe and track the issue. Cc `@workingjubilee` `@thomcc` `@chorman0773` `@rust-lang/opsem` Fixes rust-lang#73288 Fixes rust-lang#72327

Upstream Rust always requires SSE2 for x86. But back in 2017[^1][^2] we patched lang/rust to disable SSE2 for i386. At the time, it was reported that some people were still using non-SSE2 capable hardware. More recently, LLVM bugs have been discovered[^3][^4] that can result in rounding bugs and reduced accuracy when using f64 on non-SSE hardware. In weird cases, they can even cause wilder unpredictable behavior, like segfaults. Revert our change for the sake of Pentium 4 (and later) users. But add an SSE2 option. Disabling it will allow the port to be used on Pentium 3 and older CPUs. [^1]: d65b288 [^2]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223415 [^3]: rust-lang/rust#114479 [^4]: llvm/llvm-project#44218 Reviewed by: emaste Differential Revision: https://reviews.freebsd.org/D47227

x86: make SSE2 required for i686 hardfloat targets and use it to pass SIMD types The primary goal of this is to make SSE2 *required* for our i686 targets (at least for the ones that use Pentium 4 as their baseline), to ensure they cannot be affected by rust-lang#114479. This has been MCPd in rust-lang/compiler-team#808, and is tracked in rust-lang#133611. We do this by defining a new ABI that these targets select, and making SSE2 required by the ABI (that's the first commit). That's kind of a hack, but (a) it is the easiest way to make a target feature required via the target spec, and (b) we actually *can* use SSE2 for the Rust ABI now that it is required, so the second commit goes ahead and does that. Specifically, we use it in two ways: to return `f64` values in a register rather than by-ptr, and to pass vectors of size up to 128bit in a register (or, well, whatever LLVM does when passing `<4 x float>` by-val, I don't actually know if this ends up in a register). Cc `@workingjubilee` Fixes rust-lang#133611

x86: make SSE2 required for i686 hardfloat targets and use it to pass SIMD types The primary goal of this is to make SSE2 *required* for our i686 targets (at least for the ones that use Pentium 4 as their baseline), to ensure they cannot be affected by rust-lang#114479. This has been MCPd in rust-lang/compiler-team#808, and is tracked in rust-lang#133611. We do this by defining a new ABI that these targets select, and making SSE2 required by the ABI (that's the first commit). That's kind of a hack, but (a) it is the easiest way to make a target feature required via the target spec, and (b) we actually *can* use SSE2 for the Rust ABI now that it is required, so the second commit goes ahead and does that. Specifically, we use it in two ways: to return `f64` values in a register rather than by-ptr, and to pass vectors of size up to 128bit in a register (or, well, whatever LLVM does when passing `<4 x float>` by-val, I don't actually know if this ends up in a register). Cc `@workingjubilee` Fixes rust-lang#133611 try-job: aarch64-apple

x86: make SSE2 required for i686 hardfloat targets and use it to pass SIMD types The primary goal of this is to make SSE2 *required* for our i686 targets (at least for the ones that use Pentium 4 as their baseline), to ensure they cannot be affected by rust-lang#114479. This has been MCPd in rust-lang/compiler-team#808, and is tracked in rust-lang#133611. We do this by defining a new ABI that these targets select, and making SSE2 required by the ABI (that's the first commit). That's kind of a hack, but (a) it is the easiest way to make a target feature required via the target spec, and (b) we actually *can* use SSE2 for the Rust ABI now that it is required, so the second commit goes ahead and does that. Specifically, we use it in two ways: to return `f64` values in a register rather than by-ptr, and to pass vectors of size up to 128bit in a register (or, well, whatever LLVM does when passing `<4 x float>` by-val, I don't actually know if this ends up in a register). Cc `@workingjubilee` Fixes rust-lang#133611 try-job: aarch64-apple try-job: aarch64-gnu try-job: aarch64-gnu-debug try-job: test-various

x86: make SSE2 required for i686 hardfloat targets and use it to pass SIMD types The primary goal of this is to make SSE2 *required* for our i686 targets (at least for the ones that use Pentium 4 as their baseline), to ensure they cannot be affected by rust-lang#114479. This has been MCPd in rust-lang/compiler-team#808, and is tracked in rust-lang#133611. We do this by defining a new ABI that these targets select, and making SSE2 required by the ABI (that's the first commit). That's kind of a hack, but (a) it is the easiest way to make a target feature required via the target spec, and (b) we actually *can* use SSE2 for the Rust ABI now that it is required, so the second commit goes ahead and does that. Specifically, we use it in two ways: to return `f64` values in a register rather than by-ptr, and to pass vectors of size up to 128bit in a register (or, well, whatever LLVM does when passing `<4 x float>` by-val, I don't actually know if this ends up in a register). Cc `@workingjubilee` Fixes rust-lang#133611

x86: make SSE2 required for i686 hardfloat targets and use it to pass SIMD types The primary goal of this is to make SSE2 *required* for our i686 targets (at least for the ones that use Pentium 4 as their baseline), to ensure they cannot be affected by rust-lang#114479. This has been MCPd in rust-lang/compiler-team#808, and is tracked in rust-lang#133611. We do this by defining a new ABI that these targets select, and making SSE2 required by the ABI (that's the first commit). That's kind of a hack, but (a) it is the easiest way to make a target feature required via the target spec, and (b) we actually *can* use SSE2 for the Rust ABI now that it is required, so the second commit goes ahead and does that. Specifically, we use it in two ways: to return `f64` values in a register rather than by-ptr, and to pass vectors of size up to 128bit in a register (or, well, whatever LLVM does when passing `<4 x float>` by-val, I don't actually know if this ends up in a register). Cc `@workingjubilee` Fixes rust-lang#133611 try-job: aarch64-apple try-job: aarch64-gnu try-job: aarch64-gnu-debug try-job: test-various try-job: x86_64-gnu-nopt

x86: make SSE2 required for i686 hardfloat targets and use it to pass SIMD types The primary goal of this is to make SSE2 *required* for our i686 targets (at least for the ones that use Pentium 4 as their baseline), to ensure they cannot be affected by rust-lang#114479. This has been MCPd in rust-lang/compiler-team#808, and is tracked in rust-lang#133611. We do this by defining a new ABI that these targets select, and making SSE2 required by the ABI (that's the first commit). That's kind of a hack, but (a) it is the easiest way to make a target feature required via the target spec, and (b) we actually *can* use SSE2 for the Rust ABI now that it is required, so the second commit goes ahead and does that. Specifically, we use it in two ways: to return `f64` values in a register rather than by-ptr, and to pass vectors of size up to 128bit in a register (or, well, whatever LLVM does when passing `<4 x float>` by-val, I don't actually know if this ends up in a register). Cc `@workingjubilee` Fixes rust-lang#133611 try-job: aarch64-apple try-job: aarch64-gnu try-job: aarch64-gnu-debug try-job: test-various try-job: x86_64-gnu-nopt try-job: dist-i586-gnu-i586-i686-musl

add x86-sse2 (32bit) ABI that requires SSE2 target feature This is the first commit of rust-lang#135408: The primary goal of this is to make SSE2 required for our i686 targets (at least for the ones that use Pentium 4 as their baseline), to ensure they cannot be affected by rust-lang#114479. This has been MCPd in rust-lang/compiler-team#808, and is tracked in rust-lang#133611. We do this by defining a new ABI that these targets select, and making SSE2 required by the ABI (that's the first commit). That's kind of a hack, but it is the easiest way to make a target feature required via the target spec. In a follow-up change (rust-lang#135408), we can actually make use of SSE2 for the ABI, but that is running into some infrastructure issues. r? `@workingjubilee` try-job: aarch64-apple try-job: aarch64-gnu try-job: aarch64-gnu-debug try-job: test-various try-job: x86_64-gnu-nopt try-job: dist-i586-gnu-i586-i686-musl

…bilee add x86-sse2 (32bit) ABI that requires SSE2 target feature This is the first commit of rust-lang#135408: The primary goal of this is to make SSE2 required for our i686 targets (at least for the ones that use Pentium 4 as their baseline), to ensure they cannot be affected by rust-lang#114479. This has been MCPd in rust-lang/compiler-team#808, and is tracked in rust-lang#133611. We do this by defining a new ABI that these targets select, and making SSE2 required by the ABI (that's the first commit). That's kind of a hack, but it is the easiest way to make a target feature required via the target spec. In a follow-up change (rust-lang#135408), we can actually make use of SSE2 for the ABI, but that is running into some infrastructure issues. r? `@workingjubilee` try-job: aarch64-apple try-job: aarch64-gnu try-job: aarch64-gnu-debug try-job: test-various try-job: x86_64-gnu-nopt try-job: dist-i586-gnu-i586-i686-musl

Rollup merge of rust-lang#137037 - RalfJung:x86-sse2-abi, r=workingjubilee add x86-sse2 (32bit) ABI that requires SSE2 target feature This is the first commit of rust-lang#135408: The primary goal of this is to make SSE2 required for our i686 targets (at least for the ones that use Pentium 4 as their baseline), to ensure they cannot be affected by rust-lang#114479. This has been MCPd in rust-lang/compiler-team#808, and is tracked in rust-lang#133611. We do this by defining a new ABI that these targets select, and making SSE2 required by the ABI (that's the first commit). That's kind of a hack, but it is the easiest way to make a target feature required via the target spec. In a follow-up change (rust-lang#135408), we can actually make use of SSE2 for the ABI, but that is running into some infrastructure issues. r? `@workingjubilee` try-job: aarch64-apple try-job: aarch64-gnu try-job: aarch64-gnu-debug try-job: test-various try-job: x86_64-gnu-nopt try-job: dist-i586-gnu-i586-i686-musl

add x86-sse2 (32bit) ABI that requires SSE2 target feature This is the first commit of rust-lang/rust#135408: The primary goal of this is to make SSE2 required for our i686 targets (at least for the ones that use Pentium 4 as their baseline), to ensure they cannot be affected by rust-lang/rust#114479. This has been MCPd in rust-lang/compiler-team#808, and is tracked in rust-lang/rust#133611. We do this by defining a new ABI that these targets select, and making SSE2 required by the ABI (that's the first commit). That's kind of a hack, but it is the easiest way to make a target feature required via the target spec. In a follow-up change (rust-lang/rust#135408), we can actually make use of SSE2 for the ABI, but that is running into some infrastructure issues. r? `@workingjubilee` try-job: aarch64-apple try-job: aarch64-gnu try-job: aarch64-gnu-debug try-job: test-various try-job: x86_64-gnu-nopt try-job: dist-i586-gnu-i586-i686-musl

x86: make SSE2 required for i686 hardfloat targets and use it to pass SIMD types The primary goal of this is to make SSE2 *required* for our i686 targets (at least for the ones that use Pentium 4 as their baseline), to ensure they cannot be affected by rust-lang#114479. This has been MCPd in rust-lang/compiler-team#808, and is tracked in rust-lang#133611. We do this by defining a new ABI that these targets select, and making SSE2 required by the ABI (that's the first commit). That's kind of a hack, but (a) it is the easiest way to make a target feature required via the target spec, and (b) we actually *can* use SSE2 for the Rust ABI now that it is required, so the second commit goes ahead and does that. Specifically, we use it in two ways: to return `f64` values in a register rather than by-ptr, and to pass vectors of size up to 128bit in a register (or, well, whatever LLVM does when passing `<4 x float>` by-val, I don't actually know if this ends up in a register). Cc `@workingjubilee` Fixes rust-lang#133611 try-job: aarch64-apple try-job: aarch64-gnu try-job: aarch64-gnu-debug try-job: test-various try-job: x86_64-gnu-nopt try-job: dist-i586-gnu-i586-i686-musl

rustbot added the needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. label Aug 4, 2023

RalfJung added C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC O-x86 A-floating-point Area: Floating point numbers and arithmetic and removed needs-triage This issue may need triage. Remove it if it has been sufficiently triaged. labels Aug 4, 2023

ct20000901 mentioned this issue Aug 21, 2023

test: cross-platform float-point values inconsistency databendlabs/databend#12515

Open

RalfJung changed the title ~~Tracking issue: 32bit x86 targets have non-compliant floating point behavior~~ Tracking issue: 32bit x86 targets without SSE have non-compliant floating point behavior Sep 5, 2023

RalfJung changed the title ~~Tracking issue: 32bit x86 targets without SSE have non-compliant floating point behavior~~ Tracking issue: 32bit x86 targets without SSE2 have non-compliant floating point behavior Sep 5, 2023

RalfJung mentioned this issue Sep 5, 2023

Tracking issue: 32bit x86 targets lose float NaN payload in return values #115567

Open

liushuyu mentioned this issue Sep 15, 2023

core library: Disable fpmath tests for i586 ... #114042

Merged

GuentherVIII mentioned this issue Sep 17, 2023

Return f32 and f64 in XMM0 instead of FP0 on i686 #115919

Closed

RalfJung mentioned this issue Oct 2, 2023

The ABI of float types can be changed by -Ctarget-feature #116344

Open

Noratrieb added O-x86_32 Target: x86 processors, 32 bit (like i686-*) and removed O-x86-all labels Oct 25, 2023

RalfJung mentioned this issue Oct 29, 2023

Remove ability to disable some target features #116584

Closed

RalfJung mentioned this issue Nov 11, 2023

Design meeting: resolve ABI issues around target-feature rust-lang/lang-team#235

Closed

RalfJung mentioned this issue Nov 16, 2024

Forbid disabling SSE on x86 targets that have SSE in their "baseline" rust-lang/compiler-team#808

Closed

3 tasks

is-this-c mentioned this issue Nov 29, 2024

Enable SSE2 rafalh/dashfaction#307

Merged

RalfJung mentioned this issue Nov 29, 2024

Forbid disabling SSE on x86 targets that have SSE in their "baseline" #133611

Closed

quaternic mentioned this issue Jan 14, 2025

Specific test failures rust-lang/libm#401

Open

beetrees mentioned this issue Jan 25, 2025

Rework the available Cargo profiles rust-lang/libm#479

Merged

briansmith mentioned this issue Jan 26, 2025

assert!(cfg!(target_feature = "sse") && cfg!(target_feature = "sse2")) panic at build on i386, i586, FreeBSD, or many target_os=none x86 targets. briansmith/ring#1999

Closed

RalfJung mentioned this issue Feb 3, 2025

x86: use SSE2 to pass float and SIMD types #135408

Merged

workingjubilee mentioned this issue Feb 3, 2025

Our x86-32 target names are inconsistent #136495

Open

5 tasks

RalfJung mentioned this issue Feb 14, 2025

add x86-sse2 (32bit) ABI that requires SSE2 target feature #137037

Merged

This was referenced Feb 18, 2025

The status/purpose of the i586-pc-windows-msvc target is unclear #137244

Open

Remove i586-pc-windows-msvc rust-lang/compiler-team#840

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking issue: 32bit x86 targets without SSE2 have unsound floating point behavior #114479

Tracking issue: 32bit x86 targets without SSE2 have unsound floating point behavior #114479

RalfJung commented Aug 4, 2023 •

edited

Loading

DemiMarie commented Aug 4, 2023

RalfJung commented Aug 4, 2023

programmerjake commented Aug 4, 2023 •

edited

Loading

RalfJung commented Aug 14, 2023

RalfJung commented Sep 5, 2023

DemiMarie commented Sep 5, 2023

RalfJung commented Sep 5, 2023 •

edited

Loading

Tracking issue: 32bit x86 targets without SSE2 have unsound floating point behavior #114479

Tracking issue: 32bit x86 targets without SSE2 have unsound floating point behavior #114479

Comments

RalfJung commented Aug 4, 2023 • edited Loading

DemiMarie commented Aug 4, 2023

RalfJung commented Aug 4, 2023

programmerjake commented Aug 4, 2023 • edited Loading

RalfJung commented Aug 14, 2023

RalfJung commented Sep 5, 2023

DemiMarie commented Sep 5, 2023

RalfJung commented Sep 5, 2023 • edited Loading

RalfJung commented Aug 4, 2023 •

edited

Loading

programmerjake commented Aug 4, 2023 •

edited

Loading

RalfJung commented Sep 5, 2023 •

edited

Loading