| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This is the short description (`64-bit MinGW (Windows 7+)`) including
the platform requirements.
The reason for doing it like this is that this PR will be quite prone to
conflicts whenever targets get added, so it should be as simple as
possible to get it merged. Future PRs which migrate targets are scoped
to groups of targets, so they will not conflict as they can just touch
these.
This moves some of the information from the rustc book into the
compiler.
It cannot be queried yet, that is future work. It is also future work to
fill out all the descriptions, which will coincide with the work of
moving over existing target docs to the new format.
|
|
Add a new `wasm32-wasip1` target to rustc
This commit adds a new target called `wasm32-wasip1` to rustc. This new target is explained in these two MCPs:
* https://github.com/rust-lang/compiler-team/issues/607
* https://github.com/rust-lang/compiler-team/issues/695
In short, the previous `wasm32-wasi` target is going to be renamed to `wasm32-wasip1` to better live alongside the [new `wasm32-wasip2` target](https://github.com/rust-lang/rust/pull/119616). This new target is added alongside the `wasm32-wasi` target and has the exact same definition as the previous target. This PR is effectively a rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi` target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.
|
|
Remove underscore from QNX target file name
For consistency with the other QNX targets and the actual target names.
|
|
This commit adds a new target called `wasm32-wasip1` to rustc.
This new target is explained in these two MCPs:
* https://github.com/rust-lang/compiler-team/issues/607
* https://github.com/rust-lang/compiler-team/issues/695
In short, the previous `wasm32-wasi` target is going to be renamed to
`wasm32-wasip1` to better live alongside the [new
`wasm32-wasip2` target](https://github.com/rust-lang/rust/pull/119616).
This new target is added alongside the `wasm32-wasi` target and has the
exact same definition as the previous target. This PR is effectively a
rename of `wasm32-wasi` to `wasm32-wasip1`. Note, however, that
as explained in rust-lang/compiler-team#695 the previous `wasm32-wasi`
target is not being removed at this time. This change will reach stable
Rust before even a warning about the rename will be printed. At this
time this change is just the start where a new target is introduced and
users can start migrating if they support only Nightly for example.
|
|
For consistency with the other QNX targets and the actual target names.
|
|
Adds initial support for DataFlowSanitizer to the Rust compiler. It
currently supports `-Zsanitizer-dataflow-abilist`. Additional options
for it can be passed to LLVM command line argument processor via LLVM
arguments using `llvm-args` codegen option (e.g.,
`-Cllvm-args=-dfsan-combine-pointer-labels-on-load=false`).
|
|
Enable CMPXCHG16B, SSE3, SAHF/LAHF and 128-bit Atomics (in nightly) in Windows x64
As Rust plans to set Windows 10 as the minimum supported OS for target x86_64-pc-windows-msvc, I have added the cmpxchg16b and sse3 feature. Windows 10 requires CMPXCHG16B, LAHF/SAHF, and PrefetchW as stated in the requirements [here](https://download.microsoft.com/download/c/1/5/c150e1ca-4a55-4a7e-94c5-bfc8c2e785c5/Windows%2010%20Minimum%20Hardware%20Requirements.pdf). Furthermore, CPUs that meet these requirements also have SSE3 ([see](https://walbourn.github.io/directxmath-sse3-and-ssse3/))
|
|
Signed-off-by: Ryan Levick <me@ryanlevick.com>
|
|
Signed-off-by: Ryan Levick <me@ryanlevick.com>
|
|
i586_unknown_netbsd: use inline stack probes
This is one of the last two targets still using "call" stack probes.
I don't believe that this target uses call stack probes for any particular reason--inline stack probes are used on [`i686_unknown_netbsd`](https://github.com/rust-lang/rust/blob/b362939be16f9324dd9e6e36e22b606020068d75/compiler/rustc_target/src/spec/targets/i686_unknown_netbsd.rs#L8), suggesting they work on netbsd; and on [`i586_unknown_linux_gnu`](https://github.com/rust-lang/rust/blob/b362939be16f9324dd9e6e36e22b606020068d75/compiler/rustc_target/src/spec/targets/i586_unknown_linux_gnu.rs#L4) (via the base [`i686_unknown_linux_gnu`](https://github.com/rust-lang/rust/blob/b362939be16f9324dd9e6e36e22b606020068d75/compiler/rustc_target/src/spec/targets/i686_unknown_linux_gnu.rs#L9)), suggesting they work with `cpu = "pentium"`.
...although I don't have a netbsd system to test this on.
(cc `@he32)`
|
|
|
|
target: Revert default to the medium code model on LoongArch targets
This reverts commit 35dad14dfb63d77cf4a2077f1e8e9cff5a02a92b.
Fixes #121289
|
|
|
|
This reverts commit 35dad14dfb63d77cf4a2077f1e8e9cff5a02a92b.
Fixes #121289
|
|
r=workingjubilee
Fix `cfg(target_abi = "sim")` on `i386-apple-ios`
Since https://github.com/rust-lang/rust/issues/80970 is stabilizing, I went and had a look, and found that the result was wrong on `i386-apple-ios`.
r? rust-lang/macos
|
|
|
|
i386-apple-ios is also a simulator target
|
|
|
|
|
|
Updated x86_64-uwp-windows-gnu to use CMPXCHG16B and SSE3
|
|
As CMPXCHG16B is supported, I updated the max atomic width to 128-bits from 64-bits
|
|
Fixed a bug where adding CMPXCHG16B would fail due to different names in Rustc and LLVM
|
|
Rust plans to set Windows 10 as the minimum supported OS for target x86_64-pc-windows-msvc, I have added the cmpxchg16b and sse3 feature (as CPUs that meet the Windows 10 64-bit requirement also support SSE3. See https://walbourn.github.io/directxmath-sse3-and-ssse3/ )
|
|
Add unstable `-Z direct-access-external-data` cmdline flag for `rustc`
The new flag has been described in the Major Change Proposal at https://github.com/rust-lang/compiler-team/issues/707
Fixes #118053
|
|
Add armv8r-none-eabihf target for the Cortex-R52.
|
|
target: default to the medium code model on LoongArch targets
The Rust LoongArch targets have been using the default LLVM code model so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak. As [described][1] in the "Code Model" section of LoongArch ELF psABI spec v20231219, one can only make function calls as far as ±128MiB with the "normal" code model; this is insufficient for very large software containing Rust components that needs to be linked into the big text section, such as Chromium.
Because:
* we do not want to ask users to recompile std if they are to build such software,
* objects compiled with larger code models can be linked with those with smaller code models without problems, and
* the "medium" code model is comparable to the "small"/"normal" one performance-wise (same data access pattern; each function call becomes 2-insn long and indirect, but this may be relaxed back into the direct 1-insn form in a future LLVM version), but is able to perform function calls within ±128GiB,
it is better to just switch the targets to the "medium" code model, which is also "medium" in LLVM-speak.
[1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models
|
|
The Rust LoongArch targets have been using the default LLVM code model
so far, which is "small" in LLVM-speak and "normal" in LoongArch-speak.
As described in the "Code Model" section of LoongArch ELF psABI spec
v20231219 [1], one can only make function calls as far as ±128MiB with
the "normal" code model; this is insufficient for very large software
containing Rust components that needs to be linked into the big text
section, such as Chromium.
Because:
* we do not want to ask users to recompile std if they are to build
such software,
* objects compiled with larger code models can be linked with those
with smaller code models without problems, and
* the "medium" code model is comparable to the "small"/"normal" one
performance-wise (same data access pattern; each function call
becomes 2-insn long and indirect, but this may be relaxed back into
the direct 1-insn form in a future LLVM version), but is able to
perform function calls within ±128GiB,
it is better to just switch the targets to the "medium" code model,
which is also "medium" in LLVM-speak.
[1]: https://github.com/loongson/la-abi-specs/blob/v2.30/laelf.adoc#code-models
|
|
|
|
Disable packed/unpacked options for riscv linux/android.
Other riscv targets already only have the off option.
The packed/unpacked options might be supported in the future.
See upstream issue for more details:
https://github.com/llvm/llvm-project/issues/56642
Fixes #110224
|
|
This reverts commit 31ecf341250a889ac1154b2cbe3f0b97f9d008c1.
Co-authored-by: Ryan Levick <me@ryanlevick.com>
|
|
This is one of the last two targets still using "call" stack probes.
|
|
Remove --fatal-warnings on wasm targets
These were added with good intentions, but a recent change in LLVM 18 emits a warning while examining .rmeta sections in .rlib files. Since this flag is a nice-to-have and users can update their LLVM linker independently of rustc's LLVM version, we can just omit the flag.
See [this comment on wasm targets' uses of `--fatal-warnings`](https://github.com/llvm/llvm-project/pull/78658#issuecomment-1906651390).
|
|
These were added with good intentions, but a recent change in LLVM 18
emits a warning while examining .rmeta sections in .rlib files. Since
this flag is a nice-to-have and users can update their LLVM linker
independently of rustc's LLVM version, we can just omit the flag.
|
|
Signed-off-by: Ryan Levick <me@ryanlevick.com>
|
|
This also adds changes in the rust test suite in order to get a few of them to
pass.
Co-authored-by: Frank Laub <flaub@risc0.com>
Co-authored-by: Urgau <3616612+Urgau@users.noreply.github.com>
|
|
|
|
With https://reviews.llvm.org/D86310 LLVM now has i128 aligned to
16-bytes on x86 based platforms. This will be in LLVM-18. This patch
updates all our spec targets to be 16-byte aligned, and removes the
alignment when speaking to older LLVM.
This results in Rust overaligning things relative to LLVM on older LLVMs.
This alignment change was discussed in rust-lang/compiler-team#683
See #54341 for additional information about why this is happening and
where this will be useful in the future.
This *does not* stabilize `i128`/`u128` for FFI.
|
|
In LLVM 17, PowerPC targets started including function pointer alignments
in data layouts, and in Rust's update to that version (#114048), we added
the function pointer alignments. `powerpc64-unknown-linux-musl` had
`Fi64` set but this seems incorrect, and the code in LLVM would always
have computed `Fn32` because it is a MUSL target.
Signed-off-by: David Wood <david@davidtw.co>
|
|
Adds a basic assembly test checking that each target can produce assembly
and update the target tier policy to require this.
Signed-off-by: David Wood <david@davidtw.co>
|
|
The new flag has been described in the Major Change Proposal at
https://github.com/rust-lang/compiler-team/issues/707
|
|
LLVM 11 has been unsupported since 45591408b18e7f93fcf8c09210c9a5a102d84b37,
so this doesn't need to be conditional on the LLVM version.
|
|
|
|
|
|
Enable address sanitizer for MSVC targets using INFERASANLIBS linker flag
This enables address sanitizer for x86_64-pc-windows-msvc and i686-pc-windows-msvc targets when linked with the MSVC linker (link.exe) by leveraging the `/INFERASANLIBS` option to automatically find and link in Microsoft's address sanitizer runtime: <https://learn.microsoft.com/en-us/cpp/sanitizers/asan-runtime?view=msvc-170>
Implements https://github.com/rust-lang/compiler-team/issues/702
Fixes #89339 (for MSVC targets using the MSVC linker only)
Supercedes #89369
Successful x86_64-msvc build showing the sanitizer tests working: https://github.com/rust-lang/rust/actions/runs/7228346880/job/19697628258?pr=118521
|
|
|
|
Fix: Properly set vendor in i686-win7-windows-msvc target
In #118150 , setting the `vendor` field of the `i686-win7-windows-msvc` target was forgotten, preventing us from easily checking the target using `cfg(target_vendor)`.
With this PR, we set the target vendor to "win7".
|
|
|
|
Add illumos aarch64 target for rust.
This adds the newly being developed illumos aarch64 target to the rust compiler.
`@rmustacc` `@citrus-it` `@richlowe` As promissed before my hiatus :)
|
|
Add support for hexagon-unknown-none-elf as target
Still TODO: document usage details for new target
|
|
Signed-off-by: Till Wegmueller <toasterson@gmail.com>
|
