[LLVMbugs] [Bug 15249] New: rep; movsl clashes with dynamic stack realignment

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Feb 12 15:26:18 PST 2013


            Bug ID: 15249
           Summary: rep;movsl clashes with dynamic stack realignment
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
          Assignee: unassignedbugs at nondot.org
          Reporter: benny.kra at gmail.com
                CC: dimitry at andric.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Created attachment 10005
  --> http://llvm.org/bugs/attachment.cgi?id=10005&action=edit
bad asm

This caused a miscompile in firefox for reasons not entirely clear to me.

#include <stdio.h>

struct foo {
  char x[22];

__attribute__((noinline)) void bar(int *x, struct foo y) {
  printf("%p %d\n", x, y.x[0]);

__attribute__((noinline)) int foo(struct foo *x, int y) {
  int a = x->x[0];              // Force a spill.
  bar(__builtin_alloca(y), *x); // Make realignment harder with alloca.
  return a;

int main() {
  struct foo x = { { 42 } };
  printf("the answer to life the universe and everything is: %d\n",
         foo(&x, 11));
  return 0;

$ clang -Os foo.c -march=i486 -fomit-frame-pointer -mstackrealign && ./a.out
0xbfe7c220 42
the answer to life the universe and everything is: -1075330360

$ gcc -Os foo.c -march=i486 -fomit-frame-pointer && ./a.out
0xbfcdbf50 42
the answer to life the universe and everything is: 42

In the assembly we have this:
        movl    %esp, %esi
        leal    16(%esi), %eax
        movl    %eax, %esi
        movl    %ebx, (%esp)
        movw    36(%esi), %ax
        movw    %ax, 24(%esp)
        calll   bar
        addl    $32, %esp
        movl    12(%esi), %eax          # 4-byte Reload

rep;movsl demands %esi but it's not restored after the copy, and the spill
reload loads some random value instead of a stack address.

I failed to reproduce this on darwin so far because it always inlines the copy
at any optimization level. You can see the bad asm with -target
i386-unknown-freebsd though. It also reproduced on 32 bit linux given the flags

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/20130212/2e1583f0/attachment.html>

More information about the llvm-bugs mailing list