about summary refs log tree commit diff
path: root/compiler/rustc_codegen_llvm/src
diff options
context:
space:
mode:
authorMatthias Krüger <matthias.krueger@famsik.de>2024-07-31 15:36:31 +0200
committerGitHub <noreply@github.com>2024-07-31 15:36:31 +0200
commit5c6336328432d37e0ce3d83a4e4a0620a6f13c65 (patch)
tree89e4ee9cda742e81ae4e455de85bc97e36622b38 /compiler/rustc_codegen_llvm/src
parent22dbf88744649ebd3d1ba951c74739056931f4eb (diff)
parentfe6478cc539cfe17b4f5fc10f46928c6b16e6ef0 (diff)
downloadrust-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