| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
Fold aarch64 feature +fp into +neon
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON
In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a
In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.
"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.
I am... pretty sure no one is relying on this.
An argument could be made that, as we are not an "entirely proprietary" toolchain, we should not support AArch64 without floats at all. I think that's a bit excessive. However, I want to recognize the intent: programming for AArch64 should be simplified where possible. For x86-64, programmers regularly set up illegal feature configurations because it's hard to understand them, see https://github.com/rust-lang/rust/issues/89586. And per the above notes, plus the discussion in https://github.com/rust-lang/rust/issues/86941, there should be no real use cases for leaving these features split: the two should in fact always go together.
- Fixes rust-lang/rust#95002.
- Fixes rust-lang/rust#95064.
- Fixes rust-lang/rust#95122.
|
|
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON
In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a
In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.
"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.
|
|
|
|
|
|
|
|
Checking of asm! register operands now properly takes function
attributes such as #[target_feature] and #[instruction_set] into
account.
|
|
It should only include the identifier, or misspelling suggestions will be wrong.
|
|
Fix incorrect register conflict detection in asm!
This would previously incorrectly reject two subregisters that were
distinct but part of the same larger register, for example `al` and
`ah`.
|
|
This would previously incorrectly reject two subregisters that were
distinct but part of the same larger register, for example `al` and
`ah`.
|
|
|
|
|
|
Add links to the reference and rust by example for asm! docs and lints
These were previously removed in #91728 due to broken links.
cc ``@ehuss`` since this updates the rust-by-example submodule
|
|
|
|
Transition unsupported naked functions future incompatibility lint into
an error:
* Naked functions must contain a single inline assembly block.
Introduced as future incompatibility lint in 1.50 #79653.
Change into an error fixes a soundness issue described in #32489.
* Naked functions must not use any forms of inline attribute.
Introduced as future incompatibility lint in 1.56 #87652.
|
|
|
|
|
|
|
|
They are also removed from the prelude as per the decision in
https://github.com/rust-lang/rust/issues/87228.
stdarch and compiler-builtins are updated to work with the new, stable
asm! and global_asm! macros.
|
|
This no longer works now that asm! needs an explicit import. Also, it's
been over a year since asm! landed, everyone should have transitioned by
now.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Allow multiple clobber_abi in asm
Update docs
Fix aarch64 test
Combine abis
Emit duplicate ABI error, empty ABI list error
multiple clobber_abi
|
|
architectures
|
|
|
|
|
|
|
|
|
|
|
|
Remove trailing semicolon from macro call span
Macro call site spans are now less surprising/more consistent since they no longer contain a semicolon after the macro call.
The downside is that we need to do a little guesswork to get the semicolon in diagnostics. But this should not be noticeable since it is rare for the semicolon to not immediately follow the macro call.
|
|
|
|
The checking variant ensures that the offset required is not larger than
12 bits - hence we wouldn't ever need the upper 12 bits.
|
|
|
|
Add unit assignment to MIR for `asm!()`
Fixes #89305. `ExprKind::LlvmInlineAsm` gets a `push_assign_unit()` here:
https://github.com/rust-lang/rust/blob/2b6ed3b675475abc01ce7e68bb75b457f0c85684/compiler/rustc_mir_build/src/build/expr/into.rs#L475-L479
The same should probably happen for `ExprKind::InlineAsm`, which fixes the "use of possibly-uninitialized variable" error described in #89305.
|
|
|
|
Update new tests to run on aarch64 platforms.
|
|
Enable tests which are largely architecture-independent on all supported
platforms
|
|
Improve error message when _ is used for in/inout asm operands
As suggested by ```@Commeownist``` in https://github.com/rust-lang/rust/issues/72016#issuecomment-903102415.
|
|
The definition order is already close to the span order, and only differs
in corner cases.
|
|
|
|
|
