Skip to content

Handle GCC's write-only inline asm constraint in liveness, borrowck and trans. - #9850

Merged
bors merged 1 commit into
rust-lang:masterfrom
eddyb:inline-asm-constraints
Oct 18, 2013
Merged

Handle GCC's write-only inline asm constraint in liveness, borrowck and trans.#9850
bors merged 1 commit into
rust-lang:masterfrom
eddyb:inline-asm-constraints

Conversation

@eddyb

Copy link
Copy Markdown
Contributor

I've implemented analysis support for the GCC '=' write-only inline asm constraint modifier. I had more changes, for '+' (read+write) as well, but it turns out LLVM doesn't support '+' at all.

I've removed the need for wrapping each output in ExprAddrOf, as that would require unwrapping almost everywhere and it was harder to reason about in borrowck than ExprAssign's LHS.

With this change, rustc will treat (in respect to validity of accessing a local) code like this:

let x:int;unsafe{asm!("mov $1, $0":"=r"(x):"r"(5u));}

as if it were this:

let x :int;
x = 5;

Previously, the local was required to be both mutable and initialized, and the write effect wasn't recorded.

@alexcrichton

Copy link
Copy Markdown
Member

It looks to be that we have a section of constraints which are all dedicated to "output constraints", but it's possible to have an output constraint which isn't validated to be writable? It seems to me that we should merge all the constraints into one list (having = denote whether it's input or output), or we should leave the lists separate and not require = at all (because it's implied by where it's located). If we need to add the constraint for LLVM, then we can to that at trans time.

Or is there a purpose for having an output constraint without an =?

@eddyb

Copy link
Copy Markdown
ContributorAuthor

For the following C code:

intmain() {
shortport=0;
intval=0;
asm("in %1, %0" : "a"(val) : "d"(port));
}

GCC gives me this error:

<stdin>: In function ‘main’:
<stdin>:4:5: error: output operand constraint lacks ‘=’
<stdin>:4:5: error: output operand constraint lacks ‘=’
<stdin>:4:5: error: invalid lvalue in asm output 0

while clang just fails validation, without a precise cause (but better location info than GCC):

<stdin>:4:23: error: invalidoutputconstraint'a'inasm
asm("in %1, %0" : "a"(val) : "d"(port));}
^
1errorgenerated.

We can follow the same rule, require '=' at the start of output constraints, and then remove all my .starts_with("=") conditions.

Comment threadsrc/librustc/middle/trans/asm.rs Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can just be one line, no need to manually wrap. The max line length is 100 characters.

bors added a commit that referenced this pull request Oct 18, 2013
I've implemented analysis support for the [GCC '=' write-only inline asm constraint modifier](http://gcc.gnu.org/onlinedocs/gcc/Modifiers.html). I had more changes, for '+' (read+write) as well, but it turns out LLVM doesn't support '+' at all.
I've removed the need for wrapping each output in ExprAddrOf, as that would require unwrapping almost everywhere and it was harder to reason about in borrowck than ExprAssign's LHS.
With this change, rustc will treat (in respect to validity of accessing a local) code like this:
```rust
let x: int;
unsafe {
asm!("mov $1, $0" : "=r"(x) : "r"(5u));
}
```
as if it were this:
```rust
let x : int;
x = 5;
```
Previously, the local was required to be both mutable and initialized, and the write effect wasn't recorded.
@borsbors closed this Oct 18, 2013
@bors
bors merged commit 7ab0b0c into rust-lang:masterOct 18, 2013
@eddyb
eddyb deleted the inline-asm-constraints branch October 18, 2013 11:06
flip1995 pushed a commit to flip1995/rust that referenced this pull request Nov 21, 2022
Preserve `ref` on `infallible_destructuring_match` suggestion
Fixesrust-lang/rust-clippy#7499
changelog: [`infallible_destructuring_match`]: Preserve `ref` on suggestion
lnicola pushed a commit to lnicola/rust that referenced this pull request Mar 3, 2025
Don't filter out private items when completing paths in the same crate. Instead respect the `privateEditable` setting.
Fixesrust-lang#9850
LorrensP-2158466 pushed a commit to LorrensP-2158466/rust that referenced this pull request Mar 5, 2025
Don't filter out private items when completing paths in the same crate. Instead respect the `privateEditable` setting.
Fixesrust-lang#9850
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants

@eddyb@alexcrichton@luqmana@emberian@bors