explicit specialization of a function template, mark the instantiation as
constexpr if the specialization is, rather than requiring them to match.

llvm-svn: 151001

llvm-svn: 150998

llvm-svn: 150997

llvm-svn: 150996

Recording nested macro expansions is not useful, plus it fixes rdar://10893630

llvm-svn: 150995

the 'invariant.load' metadata tag onto those loads.
// rdar://10840980

llvm-svn: 150994

tests.

llvm-svn: 150993

llvm-svn: 150992

Patch by Dmitry Vyukov <dvyukov@google.com>.

Also add the relevant files to the Xcode project.

llvm-svn: 150991

Patch to fix the main.cpp compile error submitted by Dmitry Vyukov <dvyukov@google.com>.
Also add a Makefile, plus some modification to main.cpp.

llvm-svn: 150990

llvm-svn: 150989

checks:

- unix.Malloc - Checks for memory leaks, double free, use-after-free.
- unix.cstring.NullArg - Checks for null pointers passed as arguments to
CString functions + evaluates CString functions.
- unix.cstring.BadSizeArg - Checks for common anti-patterns in
strncat size argument.

llvm-svn: 150988

and introducing the lambda closure type and its function call
operator. Previously, we assumed that the lambda closure type would
land directly in the current context, and not some parent context (as
occurs with linkage specifications). Thanks to Richard for the test case.

llvm-svn: 150987

modern meta-data translation by commenting out private ivar
declarations in user source. Also, added several tests.

llvm-svn: 150985

of that variable; it will need to be recomputed with the resolved
type.

llvm-svn: 150984

llvm-svn: 150983

name mangling in the Itanium C++ ABI for lambda expressions is so
dependent on context, we encode the number used to encode each lambda
as part of the lambda closure type, and maintain this value within
Sema.

Note that there are a several pieces still missing:
  - We still get the linkage of lambda expressions wrong
  - We aren't properly numbering or mangling lambda expressions that
  occur in default function arguments or in data member initializers.
  - We aren't (de-)serializing the lambda numbering tables

llvm-svn: 150982

llvm-svn: 150979

InstCombine: Removing the base from the address calculation is only safe when the GEPs are inbounds.

llvm-svn: 150978

handled by the caching and rauw. Also fix one cache that wasn't
being added to highlighted by this patch. Update all testcases
accordingly.

This should fix the deall failure.

llvm-svn: 150977

temporary forward declaration nodes. Fixes a problem building
Chrome.

llvm-svn: 150976

derived from anything.

llvm-svn: 150975

too.

llvm-svn: 150974

llvm-svn: 150973

llvm-svn: 150972

llvm-svn: 150971

llvm-svn: 150970

llvm-svn: 150969

llvm-svn: 150965

llvm-svn: 150964

properly. Previously, we deserialized it but failed to set the
corresponding member in CXXNewExpr. Fixes <rdar://problem/10893600>.

llvm-svn: 150963

InstCombine: When comparing two GEPs that were derived from the same base pointer but use different types, expand the offset calculation and to the compare on the offset if profitable.

This came up in SmallVector code.

llvm-svn: 150962

- Ignore pointer casts.
- Also expand GEPs that aren't constantexprs when they have one use or only constant indices.

- We now compile "&foo[i] - &foo[j]" into "i - j".

llvm-svn: 150961

llvm-svn: 150960

llvm-svn: 150959

The class name is long enough without the llvm:: added.
Also bring in RefCountedBase and RefCountedBaseVPTR.

llvm-svn: 150958

llvm-svn: 150957

Teach TargetSelectionDAG about lengthening loads for vector types and set v4i8 as legal. Allow FP_TO_UINT for v4i16 from v4i32.

llvm-svn: 150956

llvm-svn: 150955

llvm-svn: 150954