[LLVMbugs] [Bug 18244] New: Backend can miscompile functions that invoke setjmp()

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=18244

            Bug ID: 18244
           Summary: Backend can miscompile functions that invoke setjmp()
           Product: tools
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: ASSIGNED
          Severity: normal
          Priority: P
         Component: llc
          Assignee: mseaborn at chromium.org
          Reporter: mseaborn at chromium.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

The backend needs to avoid reusing spill slots in functions that call setjmp().
 It does this correctly if setjmp() is called via a "call" instruction, but not
if it's called via an "invoke" instruction.

Here's an example of a program that is miscompiled as a result:

#include <stdio.h>

typedef char jmp_buf[1000];
extern "C" {
  // Declare setjmp() without "__attribute__((nothrow))":
  int setjmp(jmp_buf env);
  void longjmp(jmp_buf env, int val);
}

static int counter = 0;

__attribute__((noinline))
int f(void) {
  return ++counter;
}

__attribute__((noinline))
void g(int x, int expected) {
  if (x == expected) {
    printf("got %i (ok)\n", x);
  } else {
    printf("got %i but expected %i: ERROR\n", x, expected);
  }
}

// To test for the bug, this must be compiled with optimisation in
// order to run mem2reg and use spill slots.  But f() and g() must not
// be inlined.
int main() throw() {
  // Keep enough variables live across the setjmp() call that they
  // don't all fit in registers and the compiler allocates some spill
  // slots.
  int a1 = f();
  int a2 = f();
  int a3 = f();
  int a4 = f();
  int a5 = f();
  int a6 = f();
  int a7 = f();
  int a8 = f();
  jmp_buf buf;
  if (setjmp(buf)) {
    g(a1, 1);
    g(a2, 2);
    g(a3, 3);
    g(a4, 4);
    g(a5, 5);
    g(a6, 6);
    g(a7, 7);
    g(a8, 8);
    return 0;
  }
  // Again, keep enough variables live that they need spill slots.  A
  // correct compiler will realise that a1...aN are still live (via
  // setjmp()+longjmp()), and so not reuse the earlier spill slots.
  // An incorrect compiler will think that a1..aN are dead here and
  // wrongly reuse the earlier spill slots.
  int b1 = f();
  int b2 = f();
  int b3 = f();
  int b4 = f();
  int b5 = f();
  int b6 = f();
  int b7 = f();
  int b8 = f();
  int start = 8;
  g(b1, start + 1);
  g(b2, start + 2);
  g(b3, start + 3);
  g(b4, start + 4);
  g(b5, start + 5);
  g(b6, start + 6);
  g(b7, start + 7);
  g(b8, start + 8);
  longjmp(buf, 1);
}

On x86-64, when compiled with -O1 or -O2, this program prints:

...
got 14 but expected 6: ERROR
got 15 but expected 7: ERROR
got 16 but expected 8: ERROR

The bug is in Function::callsFunctionThatReturnsTwice(), which checks calls but
not invokes.  This is ultimately used by StackSlotColoring.cpp in its
exposesReturnsTwice() call.

This is similar to bug 18206.  An "invoke" of setjmp() can occur if:
 * setjmp() is called in an exception-handling context, e.g. in C++ a
destructor implicitly declared as "nothrow".
 * setjmp() is declared without "nothrow".  e.g. glibc's headers declare
setjmp() with "nothrow", but not all headers do.

I'll prepare a fix.

-- 
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/20131213/38f7cb78/attachment.html>