[llvm-bugs] [Bug 26802] New: [X86] Clang miscompiles an inline asm output at -O1

[via llvm-bugs]

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

            Bug ID: 26802
           Summary: [X86] Clang miscompiles an inline asm output at -O1
           Product: clang
           Version: 3.7
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: cameron.mcinally at nyu.edu
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

At -O1, Clang seems to miscompile the output of this inline assembly:

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

static inline char *string_cp(char *dest, const char *src) {
  int d0, d1, d2;

  __asm__ __volatile__("1:\tlodsb\n\t"
               "stosb\n\t"
               "testb %%al,%%al\n\t"
               "jne 1b"
               : "=&S" (d0), "=&D" (d1)
               : "0" (src), "1" (dest)
               : "memory");
  return dest;
}

int main(void) {

  const char *inpt = "Hi there.";
  char *out;
  out = (char *)malloc(32*sizeof(char));
  memset(out,'\0',32);

  printf("inpt = %s, out = %s\n",inpt,out);

  out = string_cp(out,inpt);

  printf("inpt = %s, out = %s\n",inpt,out);

  return 0;
}

The expected output is:

inpt = Hi there., out = 
inpt = Hi there., out = Hi there.

Looking at the assembly, we can see that %rax is not restored after the inline
asm loop has clobbered it.

# BB#0:                                 # %entry
        movq    %rdi, %rax
        movl    $.L.str, %esi
        #APP
.Ltmp2:
        lodsb   (%rsi), %al
        stosb   %al, %es:(%rdi)
        testb   %al, %al
        jne     .Ltmp2
        #NO_APP
        # %rax should be restored here. The loop
        # clobbers it.
        retq

Also note that this does compile correctly at -O0, and that inlining avoids the
problem at -O2.

-- 
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/20160301/692382ae/attachment.html>