This isn't put into the 'clear()' method because the information needs to stick
around (at least for a little bit) after the selection DAG is built.

llvm-svn: 142032

llvm-svn: 142031

It really doesn't, but when r141929 removed the hasSideEffects flag from
this instruction, it caused miscompilations.  I am guessing that it got
moved across a stack pointer update.

Also clear isRematerializable after checking that this instruction is
in fact never rematerialized in the nightly test suite.

llvm-svn: 142030

llvm-svn: 142029

rdar://10288916 is tracking this fix.

In the past, instcombine and other passes were promoting alloca alignment past
the natural alignment, resulting in dynamic stack realignment.  Lang's work now
prevents this from happening (LLVM commit r141599).  Now that this really 
shouldn't happen report a fatal error rather than silently generate bad code.

llvm-svn: 142028

llvm-svn: 142027

Make the step range plans capable of supporting multiple ranges.  Also make their constructors public, there isn't any good reason why you shouldn't be able to make these plans.

llvm-svn: 142026

llvm-svn: 142025

llvm-svn: 142024

avoids loading data from an external source, since those lookups were
causing some "interesting" recursion in LLDB.

This code is not efficient. I plan to remedy this inefficiency in a
follow-up commit.

llvm-svn: 142023

llvm-svn: 142022

llvm-svn: 142021

llvm-svn: 142020

Tweak the C++11 status prose a bit. We still need better user guidance on the standard library issue

llvm-svn: 142019

The callee-saved registers cannot be live across an invoke call because the
control flow may continue along the exceptional edge. When this happens, all of
the callee-saved registers are no longer valid.

llvm-svn: 142018

llvm-svn: 142017

Lack of half FP was a regression compared to llvm-gcc.

llvm-svn: 142016

user-centric list, with Clang version numbers, following GCC's lead
(and user requests).

llvm-svn: 142015

llvm-svn: 142014

llvm-svn: 142013

llvm-svn: 142012

llvm-svn: 142011

llvm-svn: 142010

llvm-svn: 142009

llvm-svn: 142008

llvm-svn: 142007

out the latest LLDB, LLVM and Clang and makes sure
they work okay together.  The buildbot is currently
Mac OS X only because it uses xcodebuild.

Right now, the portion that runs the LLDB test
suite is commented out because of code-signing
problems (specifically, on Mac OS 10.7 a UI dialog
appears asking for the user's permission to attach
to the inferior process).

You can use the buildbot like this:

./scripts/buildbot.py -b /tmp/lldb-build -l /tmp/lldb.log

/tmp/lldb-build and /tmp/lldb.log should not exist
when the script is run.

/tmp/lldb-build is a temporary directory and is
removed at the end of a normal execution.

/tmp/lldb.log is a log file that sticks around.

The buildbot does not require built versions of anything;
it will do the building itself.

llvm-svn: 142006

llvm-svn: 142005

llvm-svn: 142004

llvm-svn: 142003

llvm-svn: 142002

    assert("bad SymbolicOp.VariantKind");
To:
    assert(0 && "bad SymbolicOp.VariantKind");

llvm-svn: 142000

llvm-svn: 141999

llvm-svn: 141998

The C bindings exposed some APIs that weren't covered by the OCaml bindings

llvm-svn: 141997

OCaml's int is limited to 31 bits on 32-bit architectures, so use Int32
explicitly.
Also add an unpack_attr, and {function,param,instr}_attr functions to read
the attributes.

llvm-svn: 141996

llvm-svn: 141995

llvm-svn: 141994

llvm-svn: 141993

This makes it easier to link against LLVM libs, especially if you are using
_oasis.

llvm-svn: 141992