Simplify array bound checks and clarify comments.  One element array can have same non-zero number as lower bound as well as upper bound.

llvm-svn: 129170

llvm-svn: 129169

Fix various things in the instruction emulation code:

    - Add ability to control whether or not the emulator advances the
    PC register (in the emulation state), if the instruction itself
    does not change the pc value..

    - Fix a few typos in asm description strings.

    - Fix bug in the carry flag calculation.

llvm-svn: 129168

llvm-svn: 129167

Start overhauling static analyzer support for C++ constructors.  The inlining support isn't complete, and needs
to be reworked to model CallEnter/CallExit (just like all other calls).  For now, treat constructors mostly
like other function calls, making the analysis of C++ code just a little more useful.

llvm-svn: 129166

llvm-svn: 129165

llvm-svn: 129164

can be used even when main() isn't present in the Module, but it means that you
don't get to read argv[].

llvm-svn: 129163

llvm-svn: 129162

llvm-svn: 129161

llvm-svn: 129160

Do not use zero as an upper bound for unbounded array because upper bound zero also indicates one element array. 

llvm-svn: 129157

If lower bound is more then upper bound then consider it is an unbounded array.
An array is unbounded if non-zero lower bound is same as upper bound.
If lower bound and upper bound are zero than array has one element.

llvm-svn: 129156

llvm-svn: 129155

llvm-svn: 129153

Change -arm-trap-func= into a non-arm specific option. Now Intrinsic::trap is lowered into a call to the specified trap function at sdisel time.

llvm-svn: 129152

llvm-svn: 129149

llvm-svn: 129148

PR9650
rdar://problem/9257565

llvm-svn: 129147

PR9648
rdar://problem/9257634

llvm-svn: 129146

llvm-svn: 129145

The previous cleanup of LDRD got overzealous and removed it, causing post-RA
scheduling to get overzealous in breaking antidependencies and invalidate these instructions. Hilarity and invalid assembly ensued.

rdar://9244161

llvm-svn: 129144

This patch authored by Eric Niebler.

Many methods on the Sema class (e.g. ConvertPropertyForRValue) take Expr
pointers as in/out parameters (Expr *&).  This is especially true for the
routines that apply implicit conversions to nodes in-place.  This design is
workable only as long as those conversions cannot fail.  If they are allowed
to fail, they need a way to report their failures.  The typical way of doing
this in clang is to use an ExprResult, which has an extra bit to signal a
valid/invalid state.  Returning ExprResult is de riguour elsewhere in the Sema
interface.  We suggest changing the Expr *& parameters in the Sema interface
to ExprResult &.  This increases interface consistency and maintainability.

This interface change is important for work supporting MS-style C++
properties.  For reasons explained here
<http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013180.html>,
seemingly trivial operations like rvalue/lvalue conversions that formerly
could not fail now can.  (The reason is that given the semantics of the
feature, getter/setter method lookup cannot happen until the point of use, at
which point it may be found that the method does not exist, or it may have the
wrong type, or overload resolution may fail, or it may be inaccessible.)

llvm-svn: 129143

implement lhs's protocols. // rdar://9091389.
 

llvm-svn: 129142

llvm-svn: 129141

This code is still a long way from following best practices.

llvm-svn: 129140

llvm-svn: 129139

Teach 32-bit section loading to use the Memory Manager interface, just like
the 64-bit loading does. Tidy up a few other things here and there.

llvm-svn: 129138

Add tests for that.

llvm-svn: 129137

Something changed in commit r129112 where a few standard headers vanished from
the include chain when building on Linux.  Fix up by including limits.h for
INT_MAX and PATH_MAX where needed, and stdio.h for printf().

llvm-svn: 129130

of { i32, void ()* }. Teach the verifier to verify that, deleting copies of
checks strewn about.

llvm-svn: 129128

Chris's feedback.

llvm-svn: 129127

definitely have a path leading to them, and possibly have a path leading
to them; reflect that distinction in the warning text emitted.

llvm-svn: 129126

llvm-svn: 129124

llvm-svn: 129122

I forgot to 'svn add' this file in r129119.

llvm-svn: 129120

llvm-svn: 129119

Specifying the new arguments as NULL is appropriate for now as this is
backwards-compatible with the old invocation. 

llvm-svn: 129118

Add more test cases to exercise the logical branches related to the above change.

llvm-svn: 129117

llvm-svn: 129116