| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
makes entry_abi a lowering of the ABI string, so now it can be
```json
"entry_abi": "C",
"entry_abi": "win64",
"entry_abi": "aapcs",
```
|
|
- Add AbiMapping for encoding the nuance of deprecated ABIs
|
|
|
|
|
|
|
|
* https://maskray.me/blog/2023-06-18-port-llvm-xray-to-apple-systems
* https://github.com/llvm/llvm-project/blob/llvmorg-20.1.4/clang/lib/Driver/XRayArgs.cpp#L31
|
|
workingjubilee:aarch64-linux-should-use-frame-pointers, r=compiler-errors
aarch64-linux: Default to FramePointer::NonLeaf
For aarch64-apple and aarch64-windows, platform docs state that code must use frame pointers correctly. This is because the AAPCS64 mandates that a platform specify its frame pointer conformance requirements:
- Apple: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Respect-the-purpose-of-specific-CPU-registers
- Windows: https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers
- AAPCS64: https://github.com/ARM-software/abi-aa/blob/4492d1570eb70c8fd146623e0db65b2d241f12e7/aapcs64/aapcs64.rst#the-frame-pointer
Unwinding code either requires unwind tables or frame pointers, and on aarch64 the expectation is that one can use frame pointers for this. Most Linux targets represent a motley variety of possible distributions, so it is unclear who to defer to on conformance, other than perhaps Arm. In the absence of a specific edict for a given aarch64-linux target, Rust will assume aarch64-linux targets also use non-leaf frame pointers. This reflects what compilers like clang do.
|
|
|
|
|
|
Stabilize the avx512 target features
This PR stabilizes the AVX512 target features - see [this comment](https://github.com/rust-lang/rust/issues/111137#issuecomment-2745821279).
Tracking Issue - #44839
The target feature UI tests have been changed to `x87` (chosen because this is very unlikely to stablize ever, please comment if some other feature will be better)
related: #111137
|
|
[win][arm64] Remove 'Arm64 Hazard' undocumented MSVC option and instead disable problematic test
PR #140758 added the undocumented `/arm64hazardfree` MSVC linker flag to work around a test failure where LLVM generated code that would trip a hazard in an outdated ARM processor.
Adding this flag caused issues with LLD, as it doesn't recognize it.
Rethinking the issue, using the undocumented flag seems like the incorrect solution: there's no guarantee that the flag won't be removed in the future, or change its meaning.
Instead, I've disabled the problematic test for Arm64 Windows and have filed a bug with the MSVC team to have the check removed: <https://developercommunity.microsoft.com/t/Remove-checking-for-and-fixing-Cortex-A/10905134>
This PR supersedes #140977
r? ```@jieyouxu```
|
|
|
|
Implement Display for ``rustc_target::callconv::Conv``
Follow up of https://github.com/rust-lang/rust/pull/133103#discussion_r1885552854
|
|
For aarch64-apple and aarch64-windows, platform docs state that code
must use frame pointers correctly. This is because the AAPCS64 mandates
that a platform specify its frame pointer conformance requirements:
- Apple: https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms#Respect-the-purpose-of-specific-CPU-registers
- Windows: https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers
- AAPCS64: https://github.com/ARM-software/abi-aa/blob/4492d1570eb70c8fd146623e0db65b2d241f12e7/aapcs64/aapcs64.rst#the-frame-pointer
Unwinding code either requires unwind tables or frame pointers, and
on aarch64 the expectation is that one can use frame pointers for this.
Most Linux targets represent a motley variety of possible distributions,
so it is unclear who to defer to on conformance, other than perhaps Arm.
In the absence of a specific edict for a given aarch64-linux target,
Rust will assume aarch64-linux targets use non-leaf frame pointers.
This reflects what compilers like clang do.
|
|
disable problematic test
|
|
Unfortunately, multiple people are reporting linker warnings related to
`__rust_no_alloc_shim_is_unstable` after this change. The solution isn't
quite clear yet, let's revert to green for now, and try a reland with a
determined solution for `__rust_no_alloc_shim_is_unstable`.
This reverts commit c8b7f32434c0306db5c1b974ee43443746098a92, reversing
changes made to 667247db71ea18c4130dd018d060e7f09d589490.
|
|
Stage0 bootstrap update
This PR [follows the release process](https://forge.rust-lang.org/release/process.html#master-bootstrap-update-tuesday) to update the stage0 compiler.
The only thing of note is https://github.com/rust-lang/rust/commit/58651d1b316e268fac2100c3ae37bb502a36b8ba, which was flagged by clippy as a correctness fix. I think allowing that lint in our case makes sense, but it's worth to have a second pair of eyes on it.
r? `@Mark-Simulacrum`
|
|
|
|
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
|
|
Rollup of 3 pull requests
Successful merges:
- #140397 (Add T-compiler backports Zulip notifications)
- #140851 (Warn when `#[export_name]` is used with generic functions)
- #140862 (Enable non-leaf Frame Pointers for Arm64EC Windows)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Partially stabilize LoongArch target features
Stabilization PR for the LoongArch target features. This PR stabilizes some of the target features tracked by #44839.
Specifically, this PR stabilizes the following target features:
* f
* d
* frecipe
* lasx
* lbt
* lsx
* lvz
Docs PR: https://github.com/rust-lang/reference/pull/1707
r? `@Amanieu`
|
|
|
|
Enable non-leaf Frame Pointers for Arm64 Windows
Microsoft recommends enabling frame pointers for Arm64 Windows as it enables fast stack walking, from <https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#integer-registers>:
> The frame pointer (x29) is required for compatibility with fast stack walking used by ETW and other services. It must point to the previous {x29, x30} pair on the stack.
I'm setting this to "non-leaf" as leaf functions shouldn't be spilling registers and so won't touch the frame pointer.
|
|
|
|
Fix linking statics on Arm64EC
Arm64EC builds recently started to fail due to the linker not finding a symbol:
```
symbols.o : error LNK2001: unresolved external symbol #_ZN3std9panicking11EMPTY_PANIC17hc8d2b903527827f1E (EC Symbol)
C:\Code\hello-world\target\arm64ec-pc-windows-msvc\debug\deps\hello_world.exe : fatal error LNK1120: 1 unresolved externals
```
It turns out that `EMPTY_PANIC` is a new static variable that was being exported then imported from the standard library, but when exporting LLVM didn't prepend the name with `#` (as only functions are prefixed with this character), whereas Rust was prefixing with `#` when attempting to import it.
The fix is to have Rust not prefix statics with `#` when importing.
Adding tests discovered another issue: we need to correctly mark static exported from dylibs with `DATA`, otherwise MSVC's linker assumes they are functions and complains that there is no exit thunk for them.
CI found another bug: we only apply `DllImport` to non-local statics that aren't foreign items (i.e., in an `extern` block), that is we want to use `DllImport` for statics coming from other Rust crates. However, `__rust_no_alloc_shim_is_unstable` is a static generated by the Rust compiler if required, but downstream crates consider it a foreign item since it is declared in an `extern "Rust"` block, thus they do not apply `DllImport` to it and so fails to link if it is exported by the previous crate as `DATA`. The fix is to apply `DllImport` to foreign items that are marked with the `rustc_std_internal_symbol` attribute (i.e., we assume they aren't actually foreign and will be in some Rust crate).
Fixes #138541
---
try-job: dist-aarch64-msvc
try-job: dist-x86_64-msvc
try-job: x86_64-msvc-1
try-job: x86_64-msvc-2
|
|
|
|
[win][arm64] Disable MSVC Linker 'Arm Hazard' warning
While trying to get the aarch64-msvc build working correctly (#140136), I observed the following test failure:
From <https://github.com/rust-lang/rust/pull/140136#issuecomment-2848179657>
```
= note: main.main.d17f5fbe6225cf88-cgu.0.rcgu.o : fatal error LNK1322: cannot avoid potential ARM hazard (Cortex-A53 MPCore processor bug #843419) in section 0x57; please consider using compiler option /Gy if it was not used
```
This is warning of a code sequence that triggers a bug in Cortex-A53 processors: <https://developer.arm.com/documentation/epm048406/latest>
However, since Windows 10 isn't supported on the Cortex-A53, this warning is not required, so it can be suppressed using the undocumented `/arm64hazardfree` flag.
|
|
|
|
|
|
r=workingjubilee
Added support for `apxf` target feature
|
|
|
|
Co-authored-by: Jubilee <workingjubilee@gmail.com>
|
|
|
|
Add the AVX10 target features
Parent #138843
Adds the `avx10_target_feature` feature gate, and `avx10.1` and `avx10.2` target features.
It is confirmed that Intel is dropping AVX10/256 (see [this comment](https://github.com/rust-lang/rust/issues/111137#issuecomment-2795442288)), so this should be safe to implement now.
The LLVM fix for llvm/llvm-project#135394 was merged, and has been backported to LLVM20, and the patch has also been propagated to rustc in #140502
`@rustbot` label O-x86_64 O-x86_32 A-target-feature A-SIMD
|
|
rustc_target: RISC-V: feature addition batch 3
This is the last batch (3 of 3) for RISC-V feature enhancements intended for the version 1.88 cycle.
The author's primary criteria are:
1. The extension is ratified and unprivileged one.
2. The extension is in the RVA23U64 profile (to be a baseline of the application-class RISC-V software ecosystem in the near future), either mandatory or optional.
3. Either:
1. To be discoverable through a `riscv_hwprobe` system call on (currently unreleased) Linux 6.15 (as of rc4) or
2. Helps memory/atomics-related operations more efficient and/or more robust.
This is based on the specifications:
* [The latest ratified ISA Manuals (version 20240411)](https://lf-riscv.atlassian.net/wiki/spaces/HOME/pages/16154769/RISC-V+Technical+Specifications)
* [RVA23/RVB23 profiles](https://github.com/riscv/riscv-profiles/releases/tag/rva23-rvb23-ratified)
* [RISC-V BF16 extensions](https://github.com/riscv/riscv-bfloat16/releases/tag/v183a3dac863d7c18187a739eb52b0c8f0d16854d)
LLVM Definitions:
* [`Zicbop`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L82-87)
* [`Zicbom`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L75-L80)
* [`Zic64b`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L71-L73)
* [`Ziccamoa`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L97-L99)
* [`Ziccif`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L101-L103)
* [`Zicclsm`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L105-L107)
* [`Ziccrse`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L109-L111)
* [`Zfbfmin`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L320-L325)
* [`Zvfbfmin`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L697-L702)
* [`Zvfbfwma`](https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/RISCV/RISCVFeatures.td#L704-L710)
The `Zicbop` extension (mandatory in RVA23U64) adds prefetch hints to prepare for subsequent memory operations (will be executed as no-op if the hardware does not support this extension).
The `Zicbom` extension (mandatory in RVA23U64) adds cache block-management instructions. The author did not include this in the batch 2 (because of limited use cases compared to the `Zicboz` extension) but added because it will be discoverable from Linux (as of version 6.15-rc4). Along with `Zicbop`, Rust now supports all CMO extensions.
The `Zic64b` extension (mandatory in RVA23U64) constraints the cache block to be naturally-aligned and exactly 64 bytes. Along with CMO instructions, it can improve efficiency handling with memory (e.g. efficient memory zeroing using `Zicboz` + `Zic64b`).
The `Zicc*` extensions (mandatory in RVA23U64) add constraints to the main memory properties. They are normally satisfied in the application environment with regular OSes but profiles like RVA23U64 ensures such properties are satisfied (through those *constraint* extensions).
The `Zfbf*` and `Zvfbf*` extensions (optional in RVA23U64) add instructions to handle BF16 (BFloat16) data. Although stabilization of FP-related extensions are relatively far due to ABI-related issues, they are included in this batch because they will be discoverable from Linux (as of version 6.15-rc4).
The author also adds the extension implication: `Za64rs` → `Za128rs` (superset) which the author missed to include in #140139.
|
|
Remove `avx512dq` and `avx512vl` implication for `avx512fp16`
According to Intel, `avx512fp16` requires only `avx512bw`, but LLVM also enables `avx512vl` and `avx512dq` when `avx512fp16` is active. This is relic code, and will be fixed in LLVM soon. We should remove this from Rust too asap, especially before the stabilization of AVX512
Related:
- llvm/llvm-project#136209
- #138940
- rust-lang/stdarch#1781
- #111137
``@rustbot`` label O-x86_64 O-x86_32 A-SIMD A-target-feature T-compiler -T-libs
r? ``@Amanieu``
**Update: the LLVM fix has been merged**
cc ``@rust-lang/wg-llvm`` will it be possible to update the rustc llvm version to something after llvm/llvm-project#137450
|
|
r=workingjubilee
rustc_target: RISC-V `Zfinx` is incompatible with `{ILP32,LP64}[FD]` ABIs
Because RISC-V Calling Conventions note that:
> This means code targeting the `Zfinx` extension always uses the ILP32, ILP32E or LP64 integer calling-convention only ABIs as there is no dedicated hardware floating-point register file.
`{ILP32,LP64}[FD]` ABIs with hardware floating-point calling conventions are incompatible with the `Zfinx` extension.
This commit adds `"zfinx"` to the incompatible feature list to those ABIs and tests whether trying to add `"zdinx"` (that is analogous to `"zfinx"` but in double-precision) on a LP64D ABI configuration results in an error (it also tests extension implication; `Zdinx` requires `Zfinx` extension).
Links: RISC-V psABI specification version 1.0
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/v1.0/riscv-cc.adoc#named-abis>
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0>
|
|
Fix handling of LoongArch target features not supported by LLVM 19
Fixes #140455
|
|
Because RISC-V Calling Conventions note that:
> This means code targeting the Zfinx extension always uses the ILP32,
> ILP32E or LP64 integer calling-convention only ABIs as there is no
> dedicated hardware floating-point register file.
{ILP32,LP64}[FD] ABIs with hardware floating-point calling conventions
are incompatible with the "Zfinx" extension.
This commit adds "zfinx" to the incompatible feature list to those ABIs
and tests whether trying to add "zdinx" (that is analogous to "zfinx" but
in double-precision) on a LP64D ABI configuration results in an error
(it also tests extension implication; "Zdinx" requires "Zfinx" extension).
Link: RISC-V psABI specification version 1.0
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/releases/tag/v1.0>
|
|
This commit adds three ratified unprivileged RISC-V extensions related to
BFloat16 (BF16) handling.
Although that they are far from stabilization due to ABI issues, they are
optional extensions of the RVA23U64 profile (application-class processor
profile) and going to be discoverable from the Linux kernel
(as of version 6.15-rc4).
This commit mainly prepares runtime detection of those extensions.
|
|
This commit adds a part of RISC-V extensions that are mandatory part of
the RVA23U64 profile (application-class processor profile) and related to
memory/atomic constraints.
The Zic64b extension constrains the cache line to naturally-aligned 64 bytes
that would make certain memory operations (like zeroing the memory using
the Zicboz extension) easier.
The Zicbom and Zicbop extensions enable managing cache block-based
operations (the Zicbop contains hints that will work as a NOP when this
extension is absent and the Zicbom contains control instructions).
Of which, the Zicbom extension is going to be discoverable from the Linux
kernel (as of the version 6.15-rc4) and this commit prepares for
corresponding stdarch changes.
The Zicc* extensions add certain constraints to "the main memory" (usually
true on the user mode application on the application-class processor but
those extensions make sure such constraints exist).
|
|
The Za64rs extension (reservation set -- a primitive memory unit of LR/SC
atomic operations -- is naturally aligned and *at most* 64 bytes) is a
superset of the Za128rs extension (*at most* 128 bytes; note that smaller
the reservation set is, more fine grained control over atomics).
This commit handles this as a feature implication.
|
|
|
|
|
|
|
|
|
|
Make #![feature(let_chains)] bootstrap conditional in compiler/
Let chains have been stabilized recently in #132833, so we can remove the gating from our uses in the compiler (as the compiler uses edition 2024).
|
|
rustc_target: Adjust RISC-V feature implication
This commit adjusts feature implication of the RISC-V ISA for better feature detection from the user perspective.
The main rule is:
* If the feature `A` is a functional superset of the feature `B` (`A ⊃ B`),
`A` is to imply `B`, even if this implication is not on the manual.
Such implications (not directly written in the ISA manual) are commented as `A ⊃ B`
which means "`A` is a (functional) superset of `B`".
1. `Zbc` → `Zbkc` (add as a superset)
The `Zbkc` extension is a subset of the `Zbc` extension (`Zbc` minus `clmulr` instruction).
2. `Zkr` → (nothing) (remove dependency to `Zicsr`)
Implication to the `Zicsr` extension is removed because (although nearly harmless), the `Zkr` extension (or the `seed` CSR section) defines its own subset of the `Zicsr` extension (guaranteed to work against the `seed` CSR which needs read/write access).
3. `Zvbb` → `Zvkb` (comment as a superset)
This implication was already there but not denoted as a functional superset. This commit adds the comment.
4. `Zvfh` → `Zvfhmin` (comment as a superset)
This is similar to the case above (`Zvbb` → `Zvkb`).
5. `Zvfh` → `Zve32f` (add implication per the ISA specification)
This dependency is on the ISA manual but was missing (due to the fact that `Zvfh` indirectly implies `Zve32f` on the current implementation through `Zvfh` → `Zvfhmin` which is a functional relation). This commit ensures that this is *also* ISA-compliant in the source code level (there's no functional changes though).
6. `Zvknhb` → `Zvknha` (add as a superset)
The `Zvknhb` extension (SHA-256 / SHA-512) is a functional superset of the `Zvknha` extension (SHA-256 only).
|
|
mitigate MSVC alignment issue on x86-32
This implements mitigation for https://github.com/rust-lang/rust/issues/112480 by stopping to emit `align` attributes on loads and function arguments when building for a win32 MSVC target. MSVC is known to not properly align `u64` and similar types, and claiming to LLVM that everything is properly aligned increases the chance that this will cause problems.
Of course, the misalignment is still a bug, but we can't fix that bug, only MSVC can.
Also add an errata note to the platform support page warning users about this known problem.
try-job: `i686-msvc*`
|
