-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
asm!
evaluates read-write constraint ("+r"
) expression twice
#14936
Labels
A-inline-assembly
Area: Inline assembly (`asm!(…)`)
Comments
pnkfelix
added a commit
to pnkfelix/rust
that referenced
this issue
Jun 17, 2014
…puts. Fix rust-lang#14962. Also reordered the fields in libsyntax to reflect the order that the expressions occur in an instance of `asm!`, as an attempt to remind others of this ordering. Finally, added a couple notes about cases that may need to be further revised when/if rust-lang#14936 is addressed.
I'm pretty sure that trans has to take over the expanding. A bool can indicate a read-write constraint: Shifting trivial code from libsyntax to librustc is unfortunate. |
pczarn
added a commit
to pczarn/rust
that referenced
this issue
Aug 19, 2014
Stop read+write expressions from expanding into two occurences in the AST. Add a bool to indicate whether an operand in output position if read+write or not. Fixes rust-lang#14936
bors
added a commit
that referenced
this issue
Aug 20, 2014
It's unfortunate that the read+write operands need special treatment in the AST. A separate vec for all expressions is an alternative, but it doesn't play nicely with trans. Fixes #14936
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
When you use
"=r"(x)
, it evaluatesx
once.When you use
"+r"(x)
, it evaluatesx
twice.You would not notice the multiple evaluation of
x
when it is just a variable reference. But when it is another expression, you can observe it.I suspect this is just an oversight in the construction of the
asm!
macro (in that it should expand into a single occurrence of each of its operands, but it is probably expanding into two occurrences of the output operand expression when it is+r
).Here is some demo code:
Transcript of run (note the assertion failure shows that the out case is evaluated multiple times):
The text was updated successfully, but these errors were encountered: