[LLVMbugs] [Bug 24232] New: [X86] Inline assembly operands don't work with .intel_syntax

[bugzilla-daemon at llvm.org]

https://llvm.org/bugs/show_bug.cgi?id=24232

            Bug ID: 24232
           Summary: [X86] Inline assembly operands don't work with
                    .intel_syntax
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: rnk at google.com
                CC: llvmbugs at cs.uiuc.edu, noloader at gmail.com,
                    rafael.espindola at gmail.com, yuri at tsoft.com
    Classification: Unclassified

Consider this C code:

int mynegation(int r) {
  __asm(".intel_syntax\n"
        "negl %0\n"
        : "=r"(r)
        : "0"(r));
  return r;
}

It gives this IR:

define i32 @mynegation(i32 %r) {
entry:
  %0 = tail call i32 asm ".intel_syntax\0Anegl $0\0A",
"=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %r)
  ret i32 %0
}

Our inline asm operand support expands the $0 operand as '%ecx' and then
attempts to re-parse the inline assembly. This fails, because '%ecx' should not
have the percent in intel style assembly. We get this error:

<inline asm>:2:6: error: unknown token in expression
negl %ecx
     ^

Our current inline assembly support works by running the operands through the
old AsmPrinter infrastructure and then re-parsing with MC. If instead we could
teach the MC asm parser how to tolerate symbolic operands, we could fix this
problem without worrying about .intel_syntax directives.

Alternatively, we could hack the intel syntax parser to be OK with %. GCC
probably does this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20150723/cce6a9e8/attachment.html>