…orn3,wesleywiser

Windows x86: Change i128 to return via the vector ABI

Clang and GCC both return `i128` in xmm0 on windows-msvc and windows-gnu. Currently, Rust returns the type on the stack. Add a calling convention adjustment so we also return scalar `i128`s using the vector ABI, which makes our `i128` compatible with C.

In the future, Clang may change to return `i128` on the stack for its `-msvc` targets (more at [1]). If this happens, the change here will need to be adjusted to only affect MinGW.

Link: rust-lang#134288 (does not fix) [1]

try-job: x86_64-msvc
try-job: x86_64-msvc-ext1
try-job: x86_64-mingw-1
try-job: x86_64-mingw-2

…r=tgross35

x86_win64 ABI: do not use xmm0 with softfloat ABI

This adjusts rust-lang#134290 to not apply the new logic to targets marked as "softfloat". That fixes most instances of the issue brought up [here](rust-lang#116558 (comment)).

r? `@tgross35`

Rollup merge of rust-lang#137094 - RalfJung:softfloat-means-no-simd, r=tgross35

x86_win64 ABI: do not use xmm0 with softfloat ABI

This adjusts rust-lang#134290 to not apply the new logic to targets marked as "softfloat". That fixes most instances of the issue brought up [here](rust-lang#116558 (comment)).

r? `@tgross35`

Rust's 128-bit integers have historically been incompatible with C [1].
However, there have been a number of changes in Rust and LLVM that
mean this is no longer the case:

* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment
  proposed at rust-lang/compiler-team#683,
  implemented at rust-lang#116672.
* LLVM version of the above: resolved in LLVM, including ABI fix.
  Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]:
  Rust's data layouts adjusted at
  rust-lang#132422,
  rust-lang#132741,
  rust-lang#134115.
* LLVM version of the above: done in LLVM 20
  llvm/llvm-project#102783.
* Incorrect return convention of `i128` on Windows: adjusted to match
  GCC and Clang at rust-lang#134290.

At [3], the lang team considered it acceptable to remove `i128` from
`improper_ctypes_definitions` if the LLVM version is known to be
compatible. Time has elapsed since then and we have dropped support for
LLVM versions that do not have the x86 fixes, meaning a per-llvm-version
lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes
only came in LLVM 20 but since Rust's datalayouts have also been updated
to match, we will be using the correct alignment regardless of LLVM
version.

Closes: rust-lang#134288
Closes: rust-lang#128950

[1]: rust-lang#54341
[2]: rust-lang#128950
[3]: rust-lang/lang-team#255 (comment)

Rust's 128-bit integers have historically been incompatible with C [1].
However, there have been a number of changes in Rust and LLVM that
mean this is no longer the case:

* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment
  proposed at rust-lang/compiler-team#683,
  implemented at rust-lang#116672.
* LLVM version of the above: resolved in LLVM, including ABI fix.
  Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]:
  Rust's data layouts adjusted at
  rust-lang#132422,
  rust-lang#132741,
  rust-lang#134115.
* LLVM version of the above: done in LLVM 20
  llvm/llvm-project#102783.
* Incorrect return convention of `i128` on Windows: adjusted to match
  GCC and Clang at rust-lang#134290.

At [3], the lang team considered it acceptable to remove `i128` from
`improper_ctypes_definitions` if the LLVM version is known to be
compatible. Time has elapsed since then and we have dropped support for
LLVM versions that do not have the x86 fixes, meaning a per-llvm-version
lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes
only came in LLVM 20 but since Rust's datalayouts have also been updated
to match, we will be using the correct alignment regardless of LLVM
version.

`repr(i128)` was added to this lint in [4], but is also removed here.

Part of the decision is that `i128` should match `__int128` in C on
platforms that provide it, which documentation is updated to indicate.
We will not guarantee that `i128` matches `_BitInt(128)` since that can
be different from `__int128`. Some platforms (usually 32-bit) do not
provide `__int128`; if any ABIs are extended in the future to define it,
we will need to make sure that our ABI matches.

Closes: rust-lang#134288
Closes: rust-lang#128950

[1]: rust-lang#54341
[2]: rust-lang#128950
[3]: rust-lang/lang-team#255 (comment)
[4]: rust-lang#138282

Rust's 128-bit integers have historically been incompatible with C [1].
However, there have been a number of changes in Rust and LLVM that
mean this is no longer the case:

* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment
  proposed at rust-lang/compiler-team#683,
  implemented at rust-lang#116672.
* LLVM version of the above: resolved in LLVM, including ABI fix.
  Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]:
  Rust's data layouts adjusted at
  rust-lang#132422,
  rust-lang#132741,
  rust-lang#134115.
* LLVM version of the above: done in LLVM 20
  llvm/llvm-project#102783.
* Incorrect return convention of `i128` on Windows: adjusted to match
  GCC and Clang at rust-lang#134290.

At [3], the lang team considered it acceptable to remove `i128` from
`improper_ctypes_definitions` if the LLVM version is known to be
compatible. Time has elapsed since then and we have dropped support for
LLVM versions that do not have the x86 fixes, meaning a per-llvm-version
lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes
only came in LLVM 20 but since Rust's datalayouts have also been updated
to match, we will be using the correct alignment regardless of LLVM
version.

`repr(i128)` was added to this lint in [4], but is also removed here.

Part of the decision is that `i128` should match `__int128` in C on
platforms that provide it, which documentation is updated to indicate.
We will not guarantee that `i128` matches `_BitInt(128)` since that can
be different from `__int128`. Some platforms (usually 32-bit) do not
provide `__int128`; if any ABIs are extended in the future to define it,
we will need to make sure that our ABI matches.

Closes: rust-lang#134288
Closes: rust-lang#128950

[1]: rust-lang#54341
[2]: rust-lang#128950
[3]: rust-lang/lang-team#255 (comment)
[4]: rust-lang#138282

…-ctypes, r=traviscross,workingjubilee

Remove `i128` and `u128` from `improper_ctypes_definitions`

Rust's 128-bit integers have historically been incompatible with C [1]. However, there have been a number of changes in Rust and LLVM that mean this is no longer the case:

* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment proposed at rust-lang/compiler-team#683, implemented at rust-lang#116672.
* LLVM version of the above: resolved in LLVM, including ABI fix. Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]: Rust's data layouts adjusted at rust-lang#132422, rust-lang#132741, rust-lang#134115.
* LLVM version of the above: done in LLVM 20 llvm/llvm-project#102783.
* Incorrect return convention of `i128` on Windows: adjusted to match GCC and Clang at rust-lang#134290.

At rust-lang/lang-team#255 (comment), the lang team considered it acceptable to remove `i128` from `improper_ctypes_definitions` if the LLVM version is known to be compatible. Time has elapsed since then and we have dropped support for LLVM versions that do not have the x86 fixes, meaning a per-llvm-version lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes only came in LLVM 20 but since Rust's datalayouts have also been updated to match, we will be using the correct alignment regardless of LLVM version.

`repr(i128)` was added to this lint in rust-lang#138282, but is also removed here.

Part of the decision is that `i128` should match `__int128` in C on platforms that provide it, which documentation is updated to indicate. We will not guarantee that `i128` matches `_BitInt(128)` since that can be different from `__int128`. Some platforms (usually 32-bit) do not provide `__int128`; if any ABIs are extended in the future to define it, we will need to make sure that our ABI matches.

Closes: rust-lang#134288

[1]: rust-lang#54341
[2]: rust-lang#128950

Rollup merge of #137306 - tgross35:remove-i128-u128-improper-ctypes, r=traviscross,workingjubilee

Remove `i128` and `u128` from `improper_ctypes_definitions`

Rust's 128-bit integers have historically been incompatible with C [1]. However, there have been a number of changes in Rust and LLVM that mean this is no longer the case:

* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment proposed at rust-lang/compiler-team#683, implemented at #116672.
* LLVM version of the above: resolved in LLVM, including ABI fix. Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]: Rust's data layouts adjusted at #132422, #132741, #134115.
* LLVM version of the above: done in LLVM 20 llvm/llvm-project#102783.
* Incorrect return convention of `i128` on Windows: adjusted to match GCC and Clang at #134290.

At rust-lang/lang-team#255 (comment), the lang team considered it acceptable to remove `i128` from `improper_ctypes_definitions` if the LLVM version is known to be compatible. Time has elapsed since then and we have dropped support for LLVM versions that do not have the x86 fixes, meaning a per-llvm-version lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes only came in LLVM 20 but since Rust's datalayouts have also been updated to match, we will be using the correct alignment regardless of LLVM version.

`repr(i128)` was added to this lint in #138282, but is also removed here.

Part of the decision is that `i128` should match `__int128` in C on platforms that provide it, which documentation is updated to indicate. We will not guarantee that `i128` matches `_BitInt(128)` since that can be different from `__int128`. Some platforms (usually 32-bit) do not provide `__int128`; if any ABIs are extended in the future to define it, we will need to make sure that our ABI matches.

Closes: #134288

[1]: #54341
[2]: #128950

…r=traviscross,workingjubilee

Remove `i128` and `u128` from `improper_ctypes_definitions`

Rust's 128-bit integers have historically been incompatible with C [1]. However, there have been a number of changes in Rust and LLVM that mean this is no longer the case:

* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment proposed at rust-lang/compiler-team#683, implemented at rust-lang/rust#116672.
* LLVM version of the above: resolved in LLVM, including ABI fix. Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]: Rust's data layouts adjusted at rust-lang/rust#132422, rust-lang/rust#132741, rust-lang/rust#134115.
* LLVM version of the above: done in LLVM 20 llvm/llvm-project#102783.
* Incorrect return convention of `i128` on Windows: adjusted to match GCC and Clang at rust-lang/rust#134290.

At rust-lang/lang-team#255 (comment), the lang team considered it acceptable to remove `i128` from `improper_ctypes_definitions` if the LLVM version is known to be compatible. Time has elapsed since then and we have dropped support for LLVM versions that do not have the x86 fixes, meaning a per-llvm-version lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes only came in LLVM 20 but since Rust's datalayouts have also been updated to match, we will be using the correct alignment regardless of LLVM version.

`repr(i128)` was added to this lint in rust-lang/rust#138282, but is also removed here.

Part of the decision is that `i128` should match `__int128` in C on platforms that provide it, which documentation is updated to indicate. We will not guarantee that `i128` matches `_BitInt(128)` since that can be different from `__int128`. Some platforms (usually 32-bit) do not provide `__int128`; if any ABIs are extended in the future to define it, we will need to make sure that our ABI matches.

Closes: rust-lang/rust#134288

[1]: rust-lang/rust#54341
[2]: rust-lang/rust#128950

Rust's 128-bit integers have historically been incompatible with C [1].
However, there have been a number of changes in Rust and LLVM that
mean this is no longer the case:

* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment
  proposed at rust-lang/compiler-team#683,
  implemented at rust-lang#116672.
* LLVM version of the above: resolved in LLVM, including ABI fix.
  Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]:
  Rust's data layouts adjusted at
  rust-lang#132422,
  rust-lang#132741,
  rust-lang#134115.
* LLVM version of the above: done in LLVM 20
  llvm/llvm-project#102783.
* Incorrect return convention of `i128` on Windows: adjusted to match
  GCC and Clang at rust-lang#134290.

At [3], the lang team considered it acceptable to remove `i128` from
`improper_ctypes_definitions` if the LLVM version is known to be
compatible. Time has elapsed since then and we have dropped support for
LLVM versions that do not have the x86 fixes, meaning a per-llvm-version
lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes
only came in LLVM 20 but since Rust's datalayouts have also been updated
to match, we will be using the correct alignment regardless of LLVM
version.

`repr(i128)` was added to this lint in [4], but is also removed here.

Part of the decision is that `i128` should match `__int128` in C on
platforms that provide it, which documentation is updated to indicate.
We will not guarantee that `i128` matches `_BitInt(128)` since that can
be different from `__int128`. Some platforms (usually 32-bit) do not
provide `__int128`; if any ABIs are extended in the future to define it,
we will need to make sure that our ABI matches.

Closes: rust-lang#134288
Closes: rust-lang#128950

[1]: rust-lang#54341
[2]: rust-lang#128950
[3]: rust-lang/lang-team#255 (comment)
[4]: rust-lang#138282

Rust's 128-bit integers have historically been incompatible with C [1].
However, there have been a number of changes in Rust and LLVM that
mean this is no longer the case:

* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment
  proposed at rust-lang/compiler-team#683,
  implemented at rust-lang#116672.
* LLVM version of the above: resolved in LLVM, including ABI fix.
  Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]:
  Rust's data layouts adjusted at
  rust-lang#132422,
  rust-lang#132741,
  rust-lang#134115.
* LLVM version of the above: done in LLVM 20
  llvm/llvm-project#102783.
* Incorrect return convention of `i128` on Windows: adjusted to match
  GCC and Clang at rust-lang#134290.

At [3], the lang team considered it acceptable to remove `i128` from
`improper_ctypes_definitions` if the LLVM version is known to be
compatible. Time has elapsed since then and we have dropped support for
LLVM versions that do not have the x86 fixes, meaning a per-llvm-version
lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes
only came in LLVM 20 but since Rust's datalayouts have also been updated
to match, we will be using the correct alignment regardless of LLVM
version.

`repr(i128)` was added to this lint in [4], but is also removed here.

Part of the decision is that `i128` should match `__int128` in C on
platforms that provide it, which documentation is updated to indicate.
We will not guarantee that `i128` matches `_BitInt(128)` since that can
be different from `__int128`. Some platforms (usually 32-bit) do not
provide `__int128`; if any ABIs are extended in the future to define it,
we will need to make sure that our ABI matches.

Closes: rust-lang#134288
Closes: rust-lang#128950

[1]: rust-lang#54341
[2]: rust-lang#128950
[3]: rust-lang/lang-team#255 (comment)
[4]: rust-lang#138282

…-ctypes, r=traviscross,workingjubilee

Remove `i128` and `u128` from `improper_ctypes_definitions`

Rust's 128-bit integers have historically been incompatible with C [1]. However, there have been a number of changes in Rust and LLVM that mean this is no longer the case:

* Incorrect alignment of `i128` on x86 [1]: adjusting Rust's alignment proposed at rust-lang/compiler-team#683, implemented at rust-lang#116672.
* LLVM version of the above: resolved in LLVM, including ABI fix. Present in LLVM18 (our minimum supported version).
* Incorrect alignment of `i128` on 64-bit PowerPC, SPARC, and MIPS [2]: Rust's data layouts adjusted at rust-lang#132422, rust-lang#132741, rust-lang#134115.
* LLVM version of the above: done in LLVM 20 llvm/llvm-project#102783.
* Incorrect return convention of `i128` on Windows: adjusted to match GCC and Clang at rust-lang#134290.

At rust-lang/lang-team#255 (comment), the lang team considered it acceptable to remove `i128` from `improper_ctypes_definitions` if the LLVM version is known to be compatible. Time has elapsed since then and we have dropped support for LLVM versions that do not have the x86 fixes, meaning a per-llvm-version lint should no longer be necessary. The PowerPC, SPARC, and MIPS changes only came in LLVM 20 but since Rust's datalayouts have also been updated to match, we will be using the correct alignment regardless of LLVM version.

`repr(i128)` was added to this lint in rust-lang#138282, but is also removed here.

Part of the decision is that `i128` should match `__int128` in C on platforms that provide it, which documentation is updated to indicate. We will not guarantee that `i128` matches `_BitInt(128)` since that can be different from `__int128`. Some platforms (usually 32-bit) do not provide `__int128`; if any ABIs are extended in the future to define it, we will need to make sure that our ABI matches.

Closes: rust-lang#134288

[1]: rust-lang#54341
[2]: rust-lang#128950