| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Make changes necessary to support these types in the compiler.
|
|
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)`
|
|
remove platform-intrinsics ABI; make SIMD intrinsics be regular intrinsics
`@Amanieu` `@workingjubilee` I don't think there is any reason these need to be "special"? The [original RFC](https://rust-lang.github.io/rfcs/1199-simd-infrastructure.html) indicated eventually making them stable, but I think that is no longer the plan, so seems to me like we can clean this up a bit.
Blocked on https://github.com/rust-lang/stdarch/pull/1538, https://github.com/rust-lang/rust/pull/121542.
|
|
Stabilize `cfg_target_abi`
This stabilizes the `cfg` option called `target_abi`:
```rust
#[cfg(target_abi = "eabihf")]
```
Tracking issue: #80970
fixes #78791
resolves #80970
|
|
|
|
|
|
Fixes:
$ MAGIC_EXTRA_RUSTFLAGS=-Zmove-size-limit=4096 ./x test compiler/rustc_target
error: moving 6216 bytes
--> compiler/rustc_target/src/spec/base/apple/tests.rs:17:19
|
17 | for target in all_sim_targets {
| ^^^^^^^^^^^^^^^ value moved from here
|
= note: The current maximum size is 4096, but it can be customized with the move_size_limit attribute: `#![move_size_limit = "..."]`
= note: `-D large-assignments` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(large_assignments)]`
|
|
mark `min_exhaustive_patterns` as complete
This is step 1 and 2 of my [proposal](https://github.com/rust-lang/rust/issues/119612#issuecomment-1918097361) to move `min_exhaustive_patterns` forward. The vast majority of in-tree use cases of `exhaustive_patterns` are covered by `min_exhaustive_patterns`. There are a few cases that still require `exhaustive_patterns` in tests and they're all behind references.
r? ``@ghost``
|
|
target: Revert default to the medium code model on LoongArch targets
This reverts commit 35dad14dfb63d77cf4a2077f1e8e9cff5a02a92b.
Fixes #121289
|
|
Same default as Clang:
https://github.com/llvm/llvm-project/blob/d022f32c73c57b59a9121eba909f5034e89c628e/clang/lib/Driver/ToolChains/Darwin.cpp#L2038
|
|
|
|
|
|
|
|
Mac Catalyst uses IPHONEOS_DEPLOYMENT_TARGET to specify the deployment target, so it makes no sense to remove that variable.
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
These crates all needed specialization for `newtype_index!`, which will no
longer be necessary when the current nightly eventually becomes the next
bootstrap compiler.
|
|
|
|
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
|
|
Invert diagnostic lints.
That is, change `diagnostic_outside_of_impl` and `untranslatable_diagnostic` from `allow` to `deny`, because more than half of the compiler has been converted to use translated diagnostics.
This commit removes more `deny` attributes than it adds `allow` attributes, which proves that this change is warranted.
r? ````@davidtwco````
|
|
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.
|
|
That is, change `diagnostic_outside_of_impl` and
`untranslatable_diagnostic` from `allow` to `deny`, because more than
half of the compiler has be converted to use translated diagnostics.
This commit removes more `deny` attributes than it adds `allow`
attributes, which proves that this change is warranted.
|
|
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
|
|
riscv only supports split_debuginfo=off for now
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
|
|
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
|
|
|
|
add avx512fp16 to x86 target features
std_detect avx512fp16: https://github.com/rust-lang/stdarch/pull/1508
|
|
Remove the `abi_amdgpu_kernel` feature
The tracking issue (#51575) has been closed for 3 years, with no activity for 5.
|
|
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).
|
|
Add a new `wasm32-wasi-preview2` target
This is the initial implementation of the MCP https://github.com/rust-lang/compiler-team/issues/694 creating a new tier 3 target `wasm32-wasi-preview2`. That MCP has been seconded and will most likely be approved in a little over a week from now. For more information on the need for this target, please read the [MCP](https://github.com/rust-lang/compiler-team/issues/694).
There is one aspect of this PR that will become insta-stable once these changes reach a stable compiler:
* A new `target_family` named `wasi` is introduced. This target family incorporates all wasi targets including `wasm32-wasi` and its derivative `wasm32-wasi-preview1-threads`. The difference between `target_family = wasi` and `target_os = wasi` will become much clearer when `wasm32-wasi` is renamed to `wasm32-wasi-preview1` and the `target_os` becomes `wasm32-wasi-preview1`. You can read about this target rename in [this MCP](https://github.com/rust-lang/compiler-team/issues/695) which has also been seconded and will hopefully be officially approved soon.
Additional technical details include:
* Both `std::sys::wasi_preview2` and `std::os::wasi_preview2` have been created and mostly use `#[path]` annotations on their submodules to reach into the existing `wasi` (soon to be `wasi_preview1`) modules. Over time the differences between `wasi_preview1` and `wasi_preview2` will grow and most like all `#[path]` based module aliases will fall away.
* Building `wasi-preview2` relies on a [`wasi-sdk`](https://github.com/WebAssembly/wasi-sdk) in the same way that `wasi-preview1` does (one must include a `wasi-root` path in the `Config.toml` pointing to sysroot included in the wasi-sdk). The target should build against [wasi-sdk v21](https://github.com/WebAssembly/wasi-sdk/releases/tag/wasi-sdk-21) without modifications. However, the wasi-sdk itself is growing [preview2 support](https://github.com/WebAssembly/wasi-sdk/pull/370) so this might shift rapidly. We will be following along quickly to make sure that building the target remains possible as the wasi-sdk changes.
* This requires a [patch to libc](https://github.com/rylev/rust-libc/tree/wasm32-wasi-preview2) that we'll need to land in conjunction with this change. Until that patch lands the target won't actually build.
|
|
compiler: update freebsd and netbsd base specs.
both support thread local.
|
|
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.
|
