diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2023-10-03 08:58:47 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2023-10-03 08:58:47 +0200 |
| commit | 9eb87c39a01b0a565a2649d169feaecf4de31a1a (patch) | |
| tree | 165e956861933f47ec54abd9706d386e53592ebe /tests/rustdoc-js-std/parser-errors.js | |
| parent | 4f75af9e19d065905280ca517fd7560c73747369 (diff) | |
| parent | df911dfdd620cb0660e8c08857dc9b5e402946b6 (diff) | |
| download | rust-9eb87c39a01b0a565a2649d169feaecf4de31a1a.tar.gz rust-9eb87c39a01b0a565a2649d169feaecf4de31a1a.zip | |
Rollup merge of #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 https://github.com/rust-lang/unsafe-code-guidelines/issues/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 https://github.com/rust-lang/rust/issues/114479 to concisely describe and track the issue. Cc `@workingjubilee` `@thomcc` `@chorman0773` `@rust-lang/opsem` Fixes https://github.com/rust-lang/rust/issues/73288 Fixes https://github.com/rust-lang/rust/issues/72327
Diffstat (limited to 'tests/rustdoc-js-std/parser-errors.js')
0 files changed, 0 insertions, 0 deletions