llvm-svn: 65077

llvm-svn: 65076

llvm-svn: 65075

 - PR3463, PR3398, <rdar://problem/6553401> crash on relocatable
   symbol addresses as constants in static locals.

 - There are many more scenarious we could handle (like arithmetic on
   such an int) but this is the main use case.

llvm-svn: 65074

llvm-svn: 65073

llvm-svn: 65072

llvm-svn: 65071

appear to be constant.  I'll probably redo this and throw it all away
later once we have codegen for BlockDeclRefExprs.

llvm-svn: 65070

token-cache for clang.

llvm-svn: 65069

only occur for pointer types; they are also possible for integer types
now.
 - No intended functionality change, IntExprEvaluate doesn't return
   LValue results yet.

llvm-svn: 65066

 - Prep for handling lvalues, no intended functionality change.

llvm-svn: 65063

 - <rdar://problem/6094103> sema fails to promote type arguments to __builtin_isgreater (and friends)

llvm-svn: 65059

llvm-svn: 65056

llvm-svn: 65055

llvm-svn: 65054

manual setting of the Result.

 - Idiom now enforces that result will always have correct width and
   type; this exposed three new bugs:

    o Enum constant decl value can have different width than type
      (PR3173).

    o EvaluateInteger should not run an IntExprEvaluator over
      non-integral expressions.

    o FloatExprEvaluate was not handling casts correctly (it was
      evaluating the cast in the IntExprEvaluator!).

llvm-svn: 65053

t.c:1:10: error: missing terminating '>' character
#include <stdio.h
         ^

instead of:

t.c:1:10: error: missing terminating " character
#include <stdio.h
         ^

llvm-svn: 65052

llvm-svn: 65051

llvm-svn: 65048

retain/release checker: Fix crasher when the leak site is the same expression that allocates an object.

llvm-svn: 65047

uniquing array types.

llvm-svn: 65046

llvm-svn: 65041

llvm-svn: 65040

 - Handles assignment to Result with appropriate type.

 - Simplifies & encapsulates most direct handling of the Result value;
   prep for allowing IntExprEvaluator to deal with LValue APValues.

 - No intended functionality change.

llvm-svn: 65038

llvm-svn: 65037

llvm-svn: 65036

that this problem arises from time to time. We should find a fundamental 
solution for it.

llvm-svn: 65035

llvm-svn: 65033

 - <rdar://problem/6584606> clang/x86-64 - too many reg saves

llvm-svn: 65032

llvm-svn: 65031

already an entry and one to insert).

llvm-svn: 65030

llvm-svn: 65029

llvm-svn: 65028

llvm-svn: 65027

"after" group instead of the system group makes it so #include <limits.h>
picks up the *system* limits.h file before clang's.  This causes a failure
on linux and is definitely not what we want.

llvm-svn: 65026

llvm-svn: 65025

llvm-svn: 65024

llvm-svn: 65023

zero expression arguments.  This eliminates 2579 1-byte
mallocs when parsing Cocoa.h.

llvm-svn: 65022

llvm-svn: 65021