Clang's test suite.

llvm-svn: 68230

clang option code that is.

llvm-svn: 68221

llvm-svn: 67899

llvm-svn: 67895

LHS type and the computation result type; this encodes information into 
the AST which is otherwise non-obvious.  Fix Sema to always come up with the 
right answer for both of these types.  Fix IRGen and the analyzer to 
account for these changes.  This fixes PR2601.  The approach is inspired 
by PR2601 comment 2.

Note that this changes real *= complex in CodeGen from a silent 
miscompilation to an explicit error.

I'm not really sure that the analyzer changes are correct, or how to 
test them... someone more familiar with the analyzer should check those 
changes.

llvm-svn: 67889

llvm-svn: 67499

llvm-svn: 67165

Almost complete implementation of rvalue references. One bug, and a few unclear areas. Maybe Doug can shed some light on some of the fixmes.

llvm-svn: 67059

performance that the type of the returned llvm::Value for an expression 
matches the converted type of the clang::Expr; mismatches will cause all
sorts of errors and silent miscompilations.

llvm-svn: 66321

llvm-svn: 66319

crash in ir-gen.

llvm-svn: 66302

chosen sub-expression, rather than just evaluating the condition.

llvm-svn: 66018

first extend the integer to the correct width.

llvm-svn: 66009

llvm-svn: 65688

normal expression, and change Evaluate and IRGen to evaluate it like a 
normal expression.  This simplifies the code significantly, and fixes 
PR3396.

llvm-svn: 65622

llvm-svn: 65487

The big difference here is that (like string literal) @encode has 
array type, not pointer type.

llvm-svn: 65391

llvm-svn: 65285

stuff is mostly done.  Move BlockHasCopyDispose up.

llvm-svn: 65242

The size calculation is improved.

llvm-svn: 64994

llvm-svn: 64961

starting to work for blocks.

llvm-svn: 64570

missing-?:-true-value extension.

llvm-svn: 64505

llvm-svn: 64457

tried to put FIXMEs on the most important things to fix up.  Lots left
to do including more codegen, more documentation and cleaning code and
style cleanups.

llvm-svn: 64390

case on x86_64.

llvm-svn: 64333

subtle and non-obvious promotion rules.  We already handle += 
and +1 correctly.

llvm-svn: 64296

finishing off rdar://6520707

llvm-svn: 64295

llvm-svn: 63879

llvm-svn: 63394

Make CodeGen produce an error if we come across a non-constant initializer list that involves the GNU array-range designator extension

llvm-svn: 63327

represents an implicit value-initialization of a subobject of a
particular type. This replaces the (ab)use of CXXZeroValueInitExpr
within initializer lists for the "holes" that occur due to the use of
C99 designated initializers.

The new test case is currently XFAIL'd, because CodeGen's
ConstExprEmitter (in lib/CodeGen/CGExprConstant.cpp) needs to be
taught to value-initialize when it sees ImplicitValueInitExprs.

llvm-svn: 63317

The approach I've taken in this patch is relatively straightforward,
although the code itself is non-trivial. Essentially, as we process
an initializer list we build up a fully-explicit representation of the
initializer list, where each of the subobject initializations occurs
in order. Designators serve to "fill in" subobject initializations in
a non-linear way. The fully-explicit representation makes initializer
lists (both with and without designators) easy to grok for codegen and
later semantic analyses. We keep the syntactic form of the initializer
list linked into the AST for those clients interested in exactly what
the user wrote.

Known limitations:
  - Designating a member of a union that isn't the first member may
    result in bogus initialization (we warn about this)
  - GNU array-range designators are not supported (we warn about this)

llvm-svn: 63242

Note that there are still other issues in this area; see PR3396.

llvm-svn: 62942

sizeof expressions.

llvm-svn: 62941

alignment must always be a constant.  Just let the constant folder 
do it.

llvm-svn: 62933

 - <rdar://problem/6518844> Clang-generated bitcode crashes LLVM while compiling function pointer addition expression

llvm-svn: 62857

struct.

llvm-svn: 62585

llvm-svn: 62458

llvm-svn: 62335