-
Notifications
You must be signed in to change notification settings - Fork 13.3k
Can't designate registers in asm! macro #11300
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
Comments
Closing, because sadly this is more relevant to LLVM than rust (we just pass things through to LLVM) I've gotten pub unsafe fn inb(port: u16) -> u8 {
let ret;
asm!("inb $1, $0" : "={ax}"(ret) : "{dx}"(port) :: "(eax),(edx)" : "volatile")
return ret;
} |
The best resource I've found so far for learning inline assembly is looking at the relevant tests inside of LLVM sadly, otherwise I know of no other good documentation for all the syntax. |
Thanks, Alex. This is good enough for me. |
Oh, it definitely works correctly. There's a boot-loader written in rust with |
Alex: do you suggest looking at any tests in particular? There are quite a few. |
[`useless_conversion`]: don't lint if type parameter has unsatisfiable bounds for `.into_iter()` receiver Fixes rust-lang#11300. Before this PR, clippy assumed that if it sees a `f(x.into_iter())` call and the type at that argument position is generic over any `IntoIterator`, then the `.into_iter()` call must be useless because `x` already implements `IntoIterator`, *however* this assumption is not right if the generic parameter has more than just the `IntoIterator` bound (because other traits can be implemented for the IntoIterator target type but not the IntoIterator implementor, as can be seen in the linked issue: `<[i32; 3] as IntoIterator>::IntoIter` satisfies `ExactSizeIterator`, but `[i32; 3]` does not). So, this PR makes it check that the type parameter only has a single `IntoIterator` bound. It *might* be possible to check if the type of `x` in `f(x.into_iter())` satisfies all the bounds on the generic type parameter as defined on the function (which would allow removing the `.into_iter()` call even with multiple bounds), however I'm not sure how to do that, and the current fix should always work. **Edit:** This PR has been changed to check if any of the bounds don't hold for the type of the `.into_iter()` receiver, so we can still lint in some cases. changelog: [`useless_conversion`]: don't lint `.into_iter()` if type parameter has multiple bounds
The x86 instruction
in
requires specific registers as its operands, i.e. input indx
and output toax
.But it seems that
rustc
can't allocate these registers for it:Trying to relax the register allocation constraints simply leads to invalid assembly:
Why is it so? Is it a bug in rustc or in llvm? Any suggestion of where in the rust source code to look into would also be appreciated.
The text was updated successfully, but these errors were encountered: