-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Invalid inline assembly is silently discarded #22892
Comments
LLVM IR appears to include the inline asm, so I'm guessing this is an LLVM bug: ; ModuleID = 'mintest.0.rs'
target datalayout = "e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
@const10 = internal unnamed_addr constant i32 0
@const14 = internal unnamed_addr constant i32 128
; Function Attrs: uwtable
define internal void @_ZN4main20h4fb6a247161ac946eaaE() unnamed_addr #0 {
entry-block:
%byte = alloca i32
%port = alloca i32
store i32 0, i32* %byte
store i32 128, i32* %port
%0 = load i32* %byte
%1 = load i32* %port
call void asm sideeffect "out %al, %dx", "a,d,~{dirflag},~{fpsr},~{flags}"(i32 %0, i32 %1), !srcloc !0
ret void
}
define i64 @main(i64, i8**) unnamed_addr #1 {
top:
%2 = call i64 @_ZN2rt10lang_start20hb1b8686306685c6ftRLE(i8* bitcast (void ()* @_ZN4main20h4fb6a247161ac946eaaE to i8*), i64 %0, i8** %1)
ret i64 %2
}
declare i64 @_ZN2rt10lang_start20hb1b8686306685c6ftRLE(i8*, i64, i8**) unnamed_addr #1
attributes #0 = { uwtable "split-stack" }
attributes #1 = { "split-stack" }
!0 = !{i32 1} I'll check to see what clang does. |
C source: int main(int argc, char **argv)
{
unsigned char byte = 0;
unsigned short port = 0x80;
asm volatile("out %%al, %%dx" :: "a" (byte), "d" (port));
} clang LLVM IR ( ; ModuleID = 'mintest.c'
target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
target triple = "x86_64-unknown-linux-gnu"
; Function Attrs: nounwind uwtable
define i32 @main(i32 %argc, i8** %argv) #0 {
%1 = alloca i32, align 4
%2 = alloca i8**, align 8
%byte = alloca i8, align 1
%port = alloca i16, align 2
store i32 %argc, i32* %1, align 4
store i8** %argv, i8*** %2, align 8
store i8 0, i8* %byte, align 1
store i16 128, i16* %port, align 2
%3 = load i8* %byte, align 1
%4 = load i16* %port, align 2
call void asm sideeffect "out %al, %dx", "{ax},{dx},~{dirflag},~{fpsr},~{flags}"(i8 %3, i16 %4) #1, !srcloc !1
ret i32 0
}
attributes #0 = { nounwind uwtable "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-nans-fp-math"="false" "stack-protector-buffer-size"="8" "unsafe-fp-math"="false" "use-soft-float"="false" }
attributes #1 = { nounwind }
!llvm.ident = !{!0}
!0 = metadata !{metadata !"clang version 3.5.1 (tags/RELEASE_351/final)"}
!1 = metadata !{i32 115} So it looks like it might be a Rust bug after all; Rust should be generating |
Okay, so I looked at this again today: asm!("out %al, %dx" :: "{ax}" (byte), "{dx}" (port) :: "volatile"); seems to work just fine. The relevant LLVM documentation is for struct If Rust isn't receiving an error from LLVM about the invalid constraint, that's an LLVM bug, right? Still, I would like Rust documentation to be a little more specific about what constraints are allowed in |
This issue appears to have returned with the recent LLVM update. If the data type passed to the inline assembly does not match the register size, the assembly is not emitted into assembly. #![feature(asm)]
fn main() {
unsafe {
// - Errors, as expected
//asm!("lttr %cx" : : "{ecx}" (7*8));
// No error, no emitted instruction.
asm!("lttr %cx" : : "{rcx}" (7*8));
}
} |
This is still a problem. Title of this bug should be: Invalid inline assembly is silently discarded. |
Updated. |
Minimal test case from top comment produces, so presumably this is fixed. However, output files (
Edit: This probably means #26648 is also fixed, but I'm not sure... |
If anyone can reproduce, please reopen. I haven't been able to reproduce since the original source doesn't quite compile--we should open another issue about incomplete compiles leaving files behind. |
Might be good to add a regression test? |
Hmm, yeah. I'll reopen and mark as E-needstest. |
…hton Add tests for several E-needstest issues This PR adds a number of tests for various `E-needstest` errors. These tend to have been left open for a long time and seem unlikely to be closed otherwise. Closes rust-lang#10876. Closes rust-lang#22892. Closes rust-lang#26448. Closes rust-lang#26577. Closes rust-lang#26619. Closes rust-lang#27054. Closes rust-lang#28587. Closes rust-lang#44127. Closes rust-lang#44255. Closes rust-lang#55731. Closes rust-lang#57781.
…hton Add tests for several E-needstest issues This PR adds a number of tests for various `E-needstest` errors. These tend to have been left open for a long time and seem unlikely to be closed otherwise. Closes rust-lang#10876. Closes rust-lang#22892. Closes rust-lang#26448. Closes rust-lang#26577. Closes rust-lang#26619. Closes rust-lang#27054. Closes rust-lang#28587. Closes rust-lang#44127. Closes rust-lang#44255. Closes rust-lang#55731. Closes rust-lang#57781.
…hton Add tests for several E-needstest issues This PR adds a number of tests for various `E-needstest` errors. These tend to have been left open for a long time and seem unlikely to be closed otherwise. Closes rust-lang#10876. Closes rust-lang#22892. Closes rust-lang#26448. Closes rust-lang#26577. Closes rust-lang#26619. Closes rust-lang#27054. Closes rust-lang#28587. Closes rust-lang#44127. Closes rust-lang#44255. Closes rust-lang#55731. Closes rust-lang#57781.
…hton Add tests for several E-needstest issues This PR adds a number of tests for various `E-needstest` errors. These tend to have been left open for a long time and seem unlikely to be closed otherwise. Closes rust-lang#10876. Closes rust-lang#22892. Closes rust-lang#26448. Closes rust-lang#26577. Closes rust-lang#26619. Closes rust-lang#27054. Closes rust-lang#28587. Closes rust-lang#44127. Closes rust-lang#44255. Closes rust-lang#55731. Closes rust-lang#57781.
There seem to still be issues with this test case on |
This issue does not apply to the new The legacy |
Minimal testcase:
rustc --version
:rustc
output:(i.e., nothing)
Resulting objdump on x86_64-unknown-linux-gnu:
Unless I'm missing something, I should either get an error, or I should see "out %al, %dx" somewhere in there, but instead, absolutely nothing happens.
The text was updated successfully, but these errors were encountered: