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

in code gen.

llvm-svn: 62326

llvm-svn: 62289

make ScalarExprEmitter::EmitCompare() emit the expression with the correct type instead of always zext it to an int
this fixes codegen of simple exprs in C++ like 'if (x != 0)'

llvm-svn: 62060

llvm-svn: 61993

llvm-svn: 61314

llvm-svn: 61305

llvm-svn: 61301

simple test that actually does VLA codegen.

Note that despite the fact that the alloca isn't in the entry block, it 
should dominate all uses; this is guaranteed by the restrictions on goto 
into VLA scope in C99.

llvm-svn: 61291

llvm-svn: 60989

llvm-svn: 60943

ScalarExprEmitter::VisitBinLOr.

llvm-svn: 60415

llvm-svn: 59886

llvm-svn: 59622

value).
 - Use extra argument to EmitStoreThroughLValue to provide place to
   write update bit-field value if caller requires it.
 - This fixes several FIXMEs.

llvm-svn: 59615

llvm-svn: 59404

 - Use dotted notation for blocks related to a particular statement
   type.
 - Use .end for landing pads.

No functionality change in NDEBUG mode. :)

llvm-svn: 59210

what "cond.?" means, and this avoids quoting).

llvm-svn: 59128

This cuts another 200 lines off expr.ll, forming 23 selects.

llvm-svn: 59124

This happens for stuff like this:

x = cond1 || cond2 || cond3 || cond4;

llvm-svn: 59123