gcc exception handling: if an exception unwinds through
an invoke, then execution must branch to the invoke's
unwind target.  We previously tried to enforce this by
appending a cleanup action to every selector, however
this does not always work correctly due to an optimization
in the C++ unwinding runtime: if only cleanups would be
run while unwinding an exception, then the program just
terminates without actually executing the cleanups, as
invoke semantics would require.  I was hoping this
wouldn't be a problem, but in fact it turns out to be the
cause of all the remaining failures in the LLVM testsuite
(these also fail with -enable-correct-eh-support, so turning
on -enable-eh didn't make things worse!).  Instead we need
to append a full-blown catch-all to the end of each
selector.  The correct way of doing this depends on the
personality function, i.e. it is language dependent, so
can only be done by gcc.  Thus this patch which generalizes
the eh.selector intrinsic so that it can handle all possible
kinds of action table entries (before it didn't accomodate
cleanups): now 0 indicates a cleanup, and filters have to be
specified using the number of type infos plus one rather than
the number of type infos.  Related gcc patches will cause
Ada to pass a cleanup (0) to force the selector to always
fire, while C++ will use a C++ catch-all (null).

llvm-svn: 41484

Changed Sema::UsualArithmeticConversions to use the new API.

This fixes the following case...

_Complex double X;
double y;

void foo() {
  X = X + y;
}

[dylan:~/llvm/tools/clang] admin% ../../Debug/bin/clang complex.c -parse-ast-dump
Read top-level variable decl: 'X'
Read top-level variable decl: 'y'

void foo()
(CompoundStmt 0x2605cc0
  (BinaryOperator 0x2605ca0 '_Complex double' '='
    (DeclRefExpr 0x2605c10 '_Complex double' Decl='X' 0x2605ab0)
    (BinaryOperator 0x2605c80 '_Complex double' '+'
      (DeclRefExpr 0x2605c30 '_Complex double' Decl='X' 0x2605ab0)
      (ImplicitCastExpr 0x2605c70 '_Complex double'
        (DeclRefExpr 0x2605c50 'double' Decl='y' 0x2605ae0)))))

llvm-svn: 41483

llvm-svn: 41482

Coping 100MB array (after a warmup) shows that glibc 2.6.1 implementation on
x86-64 (core 2) is 30% faster (from 0.270917s to 0.188079s)

llvm-svn: 41479

llvm-svn: 41478

llvm-svn: 41477

Add Type::getAsBuiltinType() and Type::builtinTypesAreCompatible().
Modified Type::typesAreCompatible() to use the above.

This fixes the following bug submitted by Keith Bauer (thanks!).

int equal(char *a, const char *b)
{
    return a == b;
}

Also tweaked Sema::CheckCompareOperands() to ignore the qualifiers when
comparing two pointer types (though it doesn't relate directly to this bug).

llvm-svn: 41476

Tweak a comment and assert.

llvm-svn: 41475

Replaced ASTContext::maxComplexType() with ASTContext::getFloatingTypeOfSizeWithinDomain().

Changed Sema::UsualArithmeticConversions to correctly implement complex/float conversions, 
using maxFloatingType() with getFloatingTypeOfSizeWithinDomain().

llvm-svn: 41474

llvm-svn: 41473

llvm-svn: 41472

llvm-svn: 41471

llvm-svn: 41470

llvm-svn: 41469

llvm-svn: 41468

llvm-svn: 41467

llvm-svn: 41466

llvm-svn: 41465

llvm-svn: 41464

llvm-svn: 41463

instead of VisitBinaryOperator.

llvm-svn: 41462

Don't promote volatile loads/stores. This is needed (for example) to handle setjmp/longjmp properly.
This fixes PR1520.

llvm-svn: 41461

llvm-svn: 41460

the operand is of type CompoundAssignOperator, not just BinaryOperator.

llvm-svn: 41459

llvm-svn: 41458

llvm-svn: 41457

llvm-svn: 41456

llvm-svn: 41455

llvm-svn: 41454

t.c:3:9: warning: invalid conversion '%B'
printf("%B\a\n", p);
~~~~~~  ^

Don't beep the console or print the newline.

llvm-svn: 41453

llvm-svn: 41452

llvm-svn: 41451

llvm-svn: 41450

llvm-svn: 41449

llvm-svn: 41448

llvm-svn: 41447

llvm-svn: 41446

llvm-svn: 41445

llvm-svn: 41444

Fix bogus warnings (noticed by Chris) with array-constraints.c.

Remove bogus type conversions in Sema::GetTypeForDeclarator(). This commit
only deals with the array types (DeclaratorCheck::Array), though the
rest of this routine should be reviewed. Given the complexity of C declarators,
I don't want to change the entire routine now (will discuss with Chris tomorrow).

llvm-svn: 41443