5c63363284
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 |
||
|---|---|---|
| .. | ||
| alloc | ||
| backtrace@72265bea21 | ||
| core | ||
| panic_abort | ||
| panic_unwind | ||
| portable-simd | ||
| proc_macro | ||
| profiler_builtins | ||
| rtstartup | ||
| rustc-std-workspace-alloc | ||
| rustc-std-workspace-core | ||
| rustc-std-workspace-std | ||
| std | ||
| stdarch@df3618d9f3 | ||
| sysroot | ||
| test | ||
| unwind | ||