diff options
| author | Matthias Krüger <matthias.krueger@famsik.de> | 2024-07-31 15:36:31 +0200 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2024-07-31 15:36:31 +0200 |
| commit | 5c6336328432d37e0ce3d83a4e4a0620a6f13c65 (patch) | |
| tree | 89e4ee9cda742e81ae4e455de85bc97e36622b38 /compiler/rustc_codegen_llvm/src | |
| parent | 22dbf88744649ebd3d1ba951c74739056931f4eb (diff) | |
| parent | fe6478cc539cfe17b4f5fc10f46928c6b16e6ef0 (diff) | |
| download | rust-5c6336328432d37e0ce3d83a4e4a0620a6f13c65.tar.gz rust-5c6336328432d37e0ce3d83a4e4a0620a6f13c65.zip | |
Rollup merge of #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: #116909 try-job: x86_64-msvc try-job: x86_64-mingw
Diffstat (limited to 'compiler/rustc_codegen_llvm/src')
0 files changed, 0 insertions, 0 deletions
