[llvm-bugs] [Bug 26159] New: LLVM disregards windows’ x64 vararg ABI

[via llvm-bugs]

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

            Bug ID: 26159
           Summary: LLVM disregards windows’ x64 vararg ABI
           Product: new-bugs
           Version: 3.7
          Hardware: PC
                OS: other
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: simonas+llvm.org at kazlauskas.me
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

LLVM will reliably mis-translate code calling vararg-using functions which
targets Windows x64.

x64 ABI requires no special handling to varargs as compared to non-vararg
functions and wants some varargs to be placed into registers, not always stack.
LLVM, though, always places all of the varargs onto stack.

Here’s a few C programs that, as compiled with clang 3.7.1 on Windows x64,
produce unexpected results:

#include<stdio.h>
extern int wsprintfA(char *out, const char* in, ...);
int main() {
  char out[100];
  wsprintfA(out, "%d %f %c", 42, 42.25, 'a');
  printf("%s", out); // prints “42 f”
  return 0;
}

---

extern int wsprintfA(char *out, const char* in, ...);
int main() {
  char out[100];
  wsprintfA(out, "%d %f %c %s", 42, 42.25, 'a', "hello world"); //segfaults
  return 0;
}

(you can think of wsprintfA as of alias to sprintf, because it [essentially is
one](https://msdn.microsoft.com/en-us/library/windows/desktop/ms647550(v=vs.85).aspx))

I have verified that LLVM generated code correctly places the non-vararg
arguments into the correct registers, however it fails to do so for the
vararg-arguments.

---

I also have a minimal LLVM-IR file which reproduces the issue, but is not as
trivial to build.

-- 
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/20160115/d4ccaecd/attachment.html>