Commit Graph

154 Commits

Author SHA1 Message Date
Michael Goulet
bc4f0bb486 Pass InferCtxt to InlineAsmCtxt to properly taint on error
Split up some of the tests bc tainting causes some errors to become
suppressed
2025-03-10 14:28:09 +00:00
Michael Goulet
ef031c854d Exclude global_asm from mir_keys 2025-03-06 17:34:17 +00:00
Michael Goulet
c867b8f11d Construct MIR error body for global_asm correctly 2025-03-06 17:34:17 +00:00
Gary Guo
395b0fb4d9 Bless tests 2025-02-26 19:27:19 +00:00
Michael Goulet
b2dee4226d Better error message for unsized pointers 2025-02-24 16:20:50 +00:00
Michael Goulet
04c00585c3 Properly support thin ptrs that are only thin due to their param-env in asm macro 2025-02-24 16:20:35 +00:00
Michael Goulet
6ba39f7dc7 Make a fake body to store typeck results for global_asm 2025-02-22 00:12:07 +00:00
Jacob Pratt
575405161f
Rollup merge of #134090 - veluca93:stable-tf11, r=oli-obk
Stabilize target_feature_11

# Stabilization report

This is an updated version of https://github.com/rust-lang/rust/pull/116114, which is itself a redo of https://github.com/rust-lang/rust/pull/99767. Most of this commit and report were copied from those PRs. Thanks ```@LeSeulArtichaut``` and ```@calebzulawski!```

## Summary
Allows for safe functions to be marked with `#[target_feature]` attributes.

Functions marked with `#[target_feature]` are generally considered as unsafe functions: they are unsafe to call, cannot *generally* be assigned to safe function pointers, and don't implement the `Fn*` traits.

However, calling them from other `#[target_feature]` functions with a superset of features is safe.

```rust
// Demonstration function
#[target_feature(enable = "avx2")]
fn avx2() {}

fn foo() {
    // Calling `avx2` here is unsafe, as we must ensure
    // that AVX is available first.
    unsafe {
        avx2();
    }
}

#[target_feature(enable = "avx2")]
fn bar() {
    // Calling `avx2` here is safe.
    avx2();
}
```

Moreover, once https://github.com/rust-lang/rust/pull/135504 is merged, they can be converted to safe function pointers in a context in which calling them is safe:

```rust
// Demonstration function
#[target_feature(enable = "avx2")]
fn avx2() {}

fn foo() -> fn() {
    // Converting `avx2` to fn() is a compilation error here.
    avx2
}

#[target_feature(enable = "avx2")]
fn bar() -> fn() {
    // `avx2` coerces to fn() here
    avx2
}
```

See the section "Closures" below for justification of this behaviour.

## Test cases
Tests for this feature can be found in [`tests/ui/target_feature/`](f6cb952dc1/tests/ui/target-feature).

## Edge cases
### Closures
 * [target-feature 1.1: should closures inherit target-feature annotations? #73631](https://github.com/rust-lang/rust/issues/73631)

Closures defined inside functions marked with #[target_feature] inherit the target features of their parent function. They can still be assigned to safe function pointers and implement the appropriate `Fn*` traits.

```rust
#[target_feature(enable = "avx2")]
fn qux() {
    let my_closure = || avx2(); // this call to `avx2` is safe
    let f: fn() = my_closure;
}
```
This means that in order to call a function with #[target_feature], you must guarantee that the target-feature is available while the function, any closures defined inside it, as well as any safe function pointers obtained from target-feature functions inside it, execute.

This is usually ensured because target features are assumed to never disappear, and:
- on any unsafe call to a `#[target_feature]` function, presence of the target feature is guaranteed by the programmer through the safety requirements of the unsafe call.
- on any safe call, this is guaranteed recursively by the caller.

If you work in an environment where target features can be disabled, it is your responsibility to ensure that no code inside a target feature function (including inside a closure) runs after this (until the feature is enabled again).

**Note:** this has an effect on existing code, as nowadays closures do not inherit features from the enclosing function, and thus this strengthens a safety requirement. It was originally proposed in #73631 to solve this by adding a new type of UB: “taking a target feature away from your process after having run code that uses that target feature is UB” .
This was motivated by userspace code already assuming in a few places that CPU features never disappear from a program during execution (see i.e. 2e29bdf908/crates/std_detect/src/detect/arch/x86.rs); however, concerns were raised in the context of the Linux kernel; thus, we propose to relax that requirement to "causing the set of usable features to be reduced is unsafe; when doing so, the programmer is required to ensure that no closures or safe fn pointers that use removed features are still in scope".

* [Fix #[inline(always)] on closures with target feature 1.1 #111836](https://github.com/rust-lang/rust/pull/111836)

Closures accept `#[inline(always)]`, even within functions marked with `#[target_feature]`. Since these attributes conflict, `#[inline(always)]` wins out to maintain compatibility.

### ABI concerns
* [The extern "C" ABI of SIMD vector types depends on target features #116558](https://github.com/rust-lang/rust/issues/116558)

The ABI of some types can change when compiling a function with different target features. This could have introduced unsoundness with target_feature_11, but recent fixes (#133102, #132173) either make those situations invalid or make the ABI no longer dependent on features. Thus, those issues should no longer occur.

### Special functions
The `#[target_feature]` attribute is forbidden from a variety of special functions, such as main, current and future lang items (e.g. `#[start]`, `#[panic_handler]`), safe default trait implementations and safe trait methods.

This was not disallowed at the time of the first stabilization PR for target_features_11, and resulted in the following issues/PRs:
* [`#[target_feature]` is allowed on `main` #108645](https://github.com/rust-lang/rust/issues/108645)
* [`#[target_feature]` is allowed on default implementations #108646](https://github.com/rust-lang/rust/issues/108646)
* [#[target_feature] is allowed on #[panic_handler] with target_feature 1.1 #109411](https://github.com/rust-lang/rust/issues/109411)
* [Prevent using `#[target_feature]` on lang item functions #115910](https://github.com/rust-lang/rust/pull/115910)

## Documentation
 * Reference: [Document the `target_feature_11` feature reference#1181](https://github.com/rust-lang/reference/pull/1181)
---

cc tracking issue https://github.com/rust-lang/rust/issues/69098
cc ```@workingjubilee```
cc ```@RalfJung```
r? ```@rust-lang/lang```
2025-02-12 20:09:56 -05:00
Matthias Krüger
65d20f39f3
Rollup merge of #136239 - folkertdev:show-supported-register-classes, r=SparrowLii,jieyouxu
show supported register classes in error message

a simple diagnostic change that shows the supported register classes when an invalid one is found.

This information can be hard to find (especially for unstable targets), and this message now gives at least something to try or search for. I've followed the pattern for invalid clobber ABIs.

`@rustbot` label +A-inline-assembly
2025-02-11 18:04:34 +01:00
Esteban Küber
f0845adb0c Show diff suggestion format on verbose replacement
```
error[E0610]: `{integer}` is a primitive type and therefore doesn't have fields
  --> $DIR/attempted-access-non-fatal.rs:7:15
   |
LL |     let _ = 2.l;
   |               ^
   |
help: if intended to be a floating point literal, consider adding a `0` after the period and a `f64` suffix
   |
LL -     let _ = 2.l;
LL +     let _ = 2.0f64;
   |
```
2025-02-10 20:21:39 +00:00
Folkert de Vries
fbd30ea35f
show supported register classes
in inline assembly, show the supported register classes when an invalid one is found
2025-01-29 12:15:12 +01:00
Taiki Endo
cfb8be52b3 Remove duplicated code in RISC-V asm bad-reg test 2025-01-28 23:49:02 +09:00
Caleb Zulawski
44b2e6c07d Stabilize target_feature_11 2025-01-27 23:44:47 +01:00
Michael Goulet
92f93f6d11 Note def descr in NonConstFunctionCall 2024-12-23 22:15:32 +00:00
Taiki Endo
86e0eabc8d tests/ui/asm: Remove uses of rustc_attrs, lang_items, and decl_macro features by using minicore 2024-12-17 01:12:36 +09:00
Matthias Krüger
fed24af611
Rollup merge of #134070 - oli-obk:push-nquzymupzlsq, r=jieyouxu
Some asm! diagnostic adjustments and a papercut fix

Best reviewed commit by commit.

We forgot a `normalize` call in intrinsic checking, causing us to allow literal integers, but not named constants containing that literal. This can in theory affect stable code, but only if libstd contains a stable SIMD type that has an array length that is a named constant. I'd assume we'd have noticed by now due to asm! rejecting those outright.

The error message left me scratching my head for a bit, so I added some extra information to the diagnostic, too.
2024-12-12 08:06:59 +01:00
bors
903d2976fd Auto merge of #129181 - beetrees:asm-spans, r=pnkfelix,compiler-errors
Pass end position of span through inline ASM cookie

Before this PR, only the start position of the span was passed though the inline ASM cookie to diagnostics. LLVM 19 has full support for 64-bit inline ASM cookies; this PR uses that to pass the end position of the span in the upper 32 bits, meaning inline ASM diagnostics now point at the entire line the error occurred on, not just the first character of it.
2024-12-12 02:34:06 +00:00
bors
1daec069fb Auto merge of #128004 - folkertdev:naked-fn-asm, r=Amanieu
codegen `#[naked]` functions using global asm

tracking issue: https://github.com/rust-lang/rust/issues/90957

Fixes #124375

This implements the approach suggested in the tracking issue: use the existing global assembly infrastructure to emit the body of `#[naked]` functions. The main advantage is that we now have full control over what gets generated, and are no longer dependent on LLVM not sneakily messing with our output (inlining, adding extra instructions, etc).

I discussed this approach with `@Amanieu` and while I think the general direction is correct, there is probably a bunch of stuff that needs to change or move around here. I'll leave some inline comments on things that I'm not sure about.

Combined with https://github.com/rust-lang/rust/pull/127853, if both accepted, I think that resolves all steps from the tracking issue.

r? `@Amanieu`
2024-12-11 21:51:07 +00:00
Oli Scherer
98edb8f403 Clarify why a type is rejected for asm! 2024-12-11 20:17:37 +00:00
Oli Scherer
6d3d61f1b0 Evaluate constants in SIMD vec lengths before rejecting them 2024-12-11 20:17:37 +00:00
Oli Scherer
c04b52ae9e Add regression tests 2024-12-11 16:41:27 +00:00
Folkert
bd8f8e0631
codegen #[naked] functions using global_asm! 2024-12-10 21:41:03 +01:00
León Orell Valerian Liehr
94d780d647
Rollup merge of #131558 - sassman:feat/warnin-for-no-mangle-together-with-export-name, r=Urgau
Lint on combining `#[no_mangle]` and `#[export_name]`

This is my very first contribution to the compiler, even though I read the [chapter about lints](https://rustc-dev-guide.rust-lang.org/diagnostics.html) I'm not very certain that this ~~new lint is done right as a builtin lint~~ PR is right. I appreciate any guidance on how to improve the code.

- Add test for issue #47446
- ~~Implement the new lint `mixed_export_name_and_no_mangle` as a builtin lint (not sure if that is the right way to go)~~ Extend `unused_attributes` lint
- Add suggestion how to fix it

<details>

<summary>Old proposed new lint</summary>

> The `mixed_export_name_and_no_mangle` lint detects usage of both `#[export_name]` and `#[no_mangle]` on the same item which results on `#[no_mangle]` being ignored.
>
> *warn-by-default*
>
> ### Example
>
> ```rust
> #[no_mangle] // ignored
> #[export_name = "foo"] // takes precedences
> pub fn bar() {}
> ```
>
> ### Explanation
>
> The compiler will not respect the `#[no_mangle]` attribute when generating the symbol name for the function, as the `#[export_name]` attribute takes precedence. This can lead to confusion and is unnecessary.

</details>
2024-12-10 08:55:54 +01:00
bors
f981b2e27a Auto merge of #133659 - jieyouxu:rollup-576gh4p, r=jieyouxu
Rollup of 6 pull requests

Successful merges:

 - #131551 (Support input/output in vector registers of PowerPC inline assembly)
 - #132515 (Fix and undeprecate home_dir())
 - #132721 (CI: split x86_64-mingw job)
 - #133106 (changes old intrinsic declaration to new declaration)
 - #133496 (thread::available_parallelism for wasm32-wasip1-threads)
 - #133548 (Add `BTreeSet` entry APIs to match `HashSet`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-11-30 17:18:00 +00:00
Taiki Endo
df8feb5067 Support floats in input/output in vector registers of PowerPC inline assembly 2024-11-29 03:10:07 +09:00
Taiki Endo
0c8e36bb30 Fix target_feature handling in freg of LoongArch inline assembly 2024-11-29 03:01:33 +09:00
Taiki Endo
0f8ebba54a Support #[repr(simd)] types in input/output of PowerPC inline assembly 2024-11-29 00:24:36 +09:00
beetrees
68227a3777
Pass end position of span through inline ASM cookie 2024-11-26 13:00:08 +00:00
Matthias Krüger
3f86eddf83
Rollup merge of #131664 - taiki-e:s390x-asm-vreg-inout, r=Amanieu
Support input/output in vector registers of s390x inline assembly (under asm_experimental_reg feature)

This extends currently clobber-only vector registers (`vreg`) support to allow passing `#[repr(simd)]` types, floats (f32/f64/f128), and integers (i32/i64/i128) as input/output.

This is unstable and gated under new `#![feature(asm_experimental_reg)]` (tracking issue: https://github.com/rust-lang/rust/issues/133416). If the feature is not enabled, only clober is supported as before.

| Architecture | Register class | Target feature | Allowed types |
| ------------ | -------------- | -------------- | -------------- |
| s390x | `vreg` | `vector` | `i32`, `f32`, `i64`, `f64`, `i128`, `f128`, `i8x16`, `i16x8`, `i32x4`, `i64x2`, `f32x4`, `f64x2` |

This matches the list of types that are supported by the vector registers in LLVM:
https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/SystemZ/SystemZRegisterInfo.td#L301-L313

In addition to `core::simd` types and floats listed above, custom `#[repr(simd)]` types of the same size and type are also allowed. All allowed types other than i32/f32/i64/f64/i128, and relevant target features are currently unstable.

Currently there is no SIMD type for s390x in `core::arch`, but this is tracked in https://github.com/rust-lang/rust/issues/130869.

cc https://github.com/rust-lang/rust/issues/130869 about vector facility support in s390x
cc https://github.com/rust-lang/rust/issues/125398 & https://github.com/rust-lang/rust/issues/116909 about f128 support in asm

`@rustbot` label +O-SystemZ +A-inline-assembly
2024-11-25 07:01:37 +01:00
Gary Guo
0178ba2c25 Make asm_goto_with_outputs a separate feature gate 2024-11-24 15:24:01 +00:00
Gary Guo
73f8309300 Support use of asm goto with outputs and options(noreturn)
When labels are present, the `noreturn` option really means that asm block
won't fallthrough -- if labels are present, then outputs can still be
meaningfully used.
2024-11-24 14:18:10 +00:00
Gary Guo
b8df869ebb Fix asm goto with outputs
When outputs are used together with labels, they are considered
to be written for all destinations, not only when falling through.
2024-11-24 14:18:10 +00:00
Taiki Endo
c024d8ccdf Make s390x non-clobber-only vector register support unstable 2024-11-24 21:42:22 +09:00
Taiki Endo
2c8f6de1ba Support input/output in vector registers of s390x inline assembly 2024-11-22 04:18:14 +09:00
Matthias Krüger
395649558a
Rollup merge of #131544 - nbdd0121:asm_goto_safe_block, r=petrochenkov
Make asm label blocks safe context

Tracking issue: https://github.com/rust-lang/rust/issues/119364

`asm!()` is forced to be wrapped inside unsafe. If there's no special treatment, the label blocks would also always be unsafe with no way of opting out. It was suggested that a simple fix is to make asm label blocks safe: https://github.com/rust-lang/rust/issues/119364#issuecomment-2316037703.

`@rustbot` labels: +A-inline-assembly +F-asm
2024-11-21 11:58:37 +01:00
Sven Kanoldt
1696f534ab
fix: rust-lang/rust#47446
- Add test for issue 47446
- Implement the new lint lint_builtin_mixed_export_name_and_no_mangle
- Add suggestion how to fix it
2024-11-15 15:25:19 +01:00
Taiki Endo
965a2801a0 Stabilize Arm64EC inline assembly 2024-11-10 17:43:46 +09:00
Taiki Endo
241f82ad91 Basic inline assembly support for SPARC and SPARC64 2024-11-07 21:19:03 +09:00
bors
96477c55bc Auto merge of #131341 - taiki-e:ppc-clobber-abi, r=bzEq,workingjubilee
Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly

This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335.

This basically does a similar thing I did in https://github.com/rust-lang/rust/pull/130630 to implement `clobber_abi` for s390x, but for powerpc/powerpc64/powerpc64le.
- This also supports vector registers (as `vreg`) as clobber-only, which need to support clobbering of them to implement `clobber_abi`.
- `vreg` should be able to accept `#[repr(simd)]` types as input/output if the unstable `altivec` target feature is enabled, but `core::arch::{powerpc,powerpc64}` vector types, `#[repr(simd)]`, and `core::simd` are all unstable, so the fact that this is currently a clobber-only should not be considered a blocker of clobber_abi implementation or stabilization. So I have not implemented it in this PR.
  - See https://github.com/rust-lang/rust/pull/131551 (which is based on this PR) for a PR to implement this.
  - (I'm not sticking to whether that PR should be a separate PR or part of this PR, so I can merge that PR into this PR if needed.)

Refs:
- PPC32 SysV: Section "Function Calling Sequence" in [System V Application Binary Interface PowerPC Processor Supplement](https://refspecs.linuxfoundation.org/elf/elfspec_ppc.pdf)
- PPC64 ELFv1: Section 3.2 "Function Calling Sequence" in [64-bit PowerPC ELF Application Binary Interface Supplement](https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-CALL)
- PPC64 ELFv2: Section 2.2 "Function Calling Sequence" in [64-Bit ELF V2 ABI Specification](https://openpowerfoundation.org/specifications/64bitelfabi/)
- AIX: [Register usage and conventions](https://www.ibm.com/docs/en/aix/7.3?topic=overview-register-usage-conventions), [Special registers in the PowerPC®](https://www.ibm.com/docs/en/aix/7.3?topic=overview-special-registers-in-powerpc), [AIX vector programming](https://www.ibm.com/docs/en/aix/7.3?topic=concepts-aix-vector-programming)
- Register definition in LLVM: https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/llvm/lib/Target/PowerPC/PPCRegisterInfo.td#L189

If I understand the above four ABI documentations correctly, except for the PPC32 SysV's VR (Vector Registers) and 32-bit AIX (currently not supported by rustc)'s r13, there does not appear to be important differences in terms of implementing `clobber_abi`:
- The above four ABIs are consistent about FPR (0-13: volatile, 14-31: nonvolatile), CR (0-1,5-7: volatile, 2-4: nonvolatile), XER (volatile), and CTR (volatile).
- As for GPR, only the registers we are treating as reserved are slightly different
  - r0, r3-r12 are volatile
  - r1(sp, reserved), r14-31 are nonvolatile
  - r2(reserved) is TOC pointer in PPC64 ELF/AIX, system-reserved register in PPC32 SysV (AFAIK used as thread pointer in Linux/BSDs)
  - r13(reserved for non-32-bit-AIX) is thread pointer in PPC64 ELF, small data area pointer register in PPC32 SysV, "reserved under 64-bit environment; not restored across system calls[^r13]" in AIX)
- As for FPSCR, volatile in PPC64 ELFv1/AIX, some fields are volatile only in certain situations (rest are volatile) in PPC32 SysV/PPC64 ELFv2.
- As for VR (Vector Registers), it is not mentioned in PPC32 SysV, v0-v19 are volatile in both in PPC64 ELF/AIX, v20-v31 are nonvolatile in PPC64 ELF, reserved or nonvolatile depending on the ABI ([vec-extabi vs vec-default in LLVM](https://reviews.llvm.org/D89684), we are [using vec-extabi](https://github.com/rust-lang/rust/pull/131341#discussion_r1797693299)) in AIX:
  > When the default Vector enabled mode is used, these registers are reserved and must not be used.
  > In the extended ABI vector enabled mode, these registers are nonvolatile and their values are preserved across function calls

  I left [FIXME comment about PPC32 SysV](https://github.com/rust-lang/rust/pull/131341#discussion_r1790496095) and added ABI check for AIX.
- As for VRSAVE, it is not mentioned in PPC32 SysV, nonvolatile in PPC64 ELFv1, reserved in PPC64 ELFv2/AIX
- As for VSCR, it is not mentioned in PPC32 SysV/PPC64 ELFv1, some fields are volatile only in certain situations (rest are volatile) in PPC64 ELFv2, volatile in AIX

We are currently treating r1-r2, r13 (non-32-bit-AIX), r29-r31, LR, CTR, and VRSAVE as reserved.
We are currently not processing anything about FPSCR and VSCR, but I feel those are things that should be processed by `preserves_flags` rather than `clobber_abi` if we need to do something about them. (However, PPCRegisterInfo.td in LLVM does not seem to define anything about them.)

Replaces #111335 and #124279

cc `@ecnelises` `@bzEq` `@lu-zero`

r? `@Amanieu`

`@rustbot` label +O-PowerPC +A-inline-assembly

[^r13]: callee-saved, according to [LLVM](6a6af0246b/llvm/lib/Target/PowerPC/PPCCallingConv.td (L322)) and [GCC](a9173a50e7/gcc/config/rs6000/rs6000.h (L859)).
2024-11-05 03:13:47 +00:00
Taiki Endo
b07232d95d Move tests/ui/abi/riscv32e-registers.rs to tests/ui/asm/riscv
This also adds comments explaining the difference to bad-reg.rs.
2024-11-03 18:32:04 +09:00
Jieyou Xu
5596a592e3 Adjust tests to use minicore and rebless 2024-11-02 21:59:27 +08:00
Taiki Endo
e97ba53879 Add bad-reg inline assembly ui test for RISC-V and s390x 2024-11-02 21:37:03 +08:00
Taiki Endo
d19517dcd0 Support clobber_abi and vector registers (clobber-only) in PowerPC inline assembly 2024-11-02 20:26:08 +09:00
Taiki Endo
d858dfedbb Fix clobber_abi and disallow SVE-related registers in Arm64EC inline assembly 2024-10-14 05:30:45 +09:00
Gary Guo
809dc73d90 Make asm label blocks safe context
`asm!()` is forced to be wrapped inside unsafe. If there's no special
treatment, the label blocks would also always be unsafe with no way
of opting out.
2024-10-11 11:54:30 +01:00
Folkert de Vries
5fc60d1e52 various fixes for naked_asm! implementation
- fix for divergence
- fix error message
- fix another cranelift test
- fix some cranelift things
- don't set the NORETURN option for naked asm
- fix use of naked_asm! in doc comment
- fix use of naked_asm! in run-make test
- use `span_bug` in unreachable branch
2024-10-06 19:00:09 +02:00
Folkert de Vries
562ec5a6fb disallow asm! in #[naked] functions
also disallow the `noreturn` option, and infer `naked_asm!` as `!`
2024-10-06 18:12:25 +02:00
Folkert
47b42bef32 use naked_asm! in naked-function tests 2024-10-06 18:12:25 +02:00
Folkert
0aec55504c use naked_asm! in tests/ui/asm/naked-functions.rs 2024-10-06 18:12:25 +02:00
Matthias Krüger
fd2785f67a
Rollup merge of #130895 - RalfJung:asm-tests, r=nnethercote
make type-check-4 asm tests about non-const expressions

These tests recently got changed in https://github.com/rust-lang/rust/pull/129759. I asked the PR author to make the tests read from a `static mut` (rather than just making them "pass"), but I now think that was a mistake: previously the tests failed because the const was not a valid const expression, after the PR they failed because the const failed to evaluate.

So this PR restores the tests to "fail because the const is not a valid const expression". That can be done in a target-independent way so I unified the x86 and aarch64 tests into one.

Cc `@oli-obk` as the original [author](0d88631059) of these tests -- not sure if you still remember what they were intended to test.
2024-09-30 14:33:46 +02:00