ocu vectors should not treat bitcasts from int <-> vector as a splat
unless it is of the element type.

llvm-svn: 46664

llvm-svn: 46651

llvm-svn: 46599

llvm-svn: 46572

codegen of calls to functions without a prototype and varargs functions, 
including printf.

llvm-svn: 46543

already used.

llvm-svn: 46519

llvm-svn: 46515

llvm-svn: 46480

llvm-svn: 46260

__builtin_overload takes 2 or more arguments:
0) a non-zero constant-expr for the number of arguments the overloaded 
   functions will take
1) the arguments to pass to the matching overloaded function
2) a list of functions to match.

The return type of __builtin_overload is inferred from the function whose args
match the types of the arguments passed to the builtin.  For example:

float a;
float sinf(float);
int   sini(int);

float b = __builtin_overload(1, a, sini, sinf);

Says that we are overloading functions that take one argument, and trying to 
pass an argument of the same type as 'a'.  sini() does not match since it takes
and argument of type int.  sinf does match, so at codegen time this will turn
into float b = sinf(a);

llvm-svn: 46132

some naming inconsistencies in the names of classes pertaining to Objective-C
support in clang.

llvm-svn: 45715

llvm-svn: 45531

llvm-svn: 45530

Add codegen support and test for said casts.

llvm-svn: 45443

llvm-svn: 45440

discussion of this change.

llvm-svn: 45410

llvm-svn: 45361

llvm-svn: 45358

Turns out the LLVMFoldingBuilder can fold InsertElement. Knowing this, we can get rid of our special casing of constants when creating vectors.

llvm-svn: 45145

llvm-svn: 45062

llvm-svn: 44908

SourceManager is passed by reference, allowing the SourceManager to be
associated with a specific translation unit, and not the entire execution
of the driver.

Modified all users of Diagnostics to comply with this new interface.

Integrated SourceManager as a member variable of TargetInfo. TargetInfo will
eventually be associated with a single translation unit (just like
SourceManager).

Made the SourceManager reference in ASTContext private. Provided accessor
getSourceManager() for clients to use instead. Modified clients to comply with
new interface.

llvm-svn: 44878

compiles again on Linux.

llvm-svn: 44821

llvm-svn: 44806

Implement CodeGen for vectors. Don't create unnecessary conversion instructions if the value to be converted is a constant.

llvm-svn: 44606

llvm-svn: 44529

llvm-svn: 44503

llvm-svn: 44454

missing middle expression, and fix a codegen bug where
we didn't correctly promote the condition to the right 
result type.  This fixes PR1824.

llvm-svn: 44322

llvm-svn: 44160

llvm-svn: 43588

llvm-svn: 43516

llvm-svn: 43508

llvm-svn: 43439

llvm-svn: 43365

some code.

llvm-svn: 43322

llvm-svn: 43301

llvm-svn: 43300

Silenced some VC++ warnings.
Had to rephrase a partial specialization of the IntrospectionTrait struct in SerializationTest.cpp, please review.
Added a compiler specific workaround in IdentifierTable.h. Is that the way to fix this kind of issues?

llvm-svn: 43074

Move type compatibility predicates from Type to ASTContext. In addition, the predicates are now instance methods (they were previously static class methods on Type).

This allowed me to fix the following hack from this weekend...

// FIXME: Devise a way to do this without using strcmp.
// Would like to say..."return getAsStructureType() == IdStructType;", but
// we don't have a pointer to ASTContext.
bool Type::isObjcIdType() const {
  if (const RecordType *RT = getAsStructureType())
    return !strcmp(RT->getDecl()->getName(), "objc_object");
  return false;
}

...which is now...

bool isObjcIdType(QualType T) const {
  return T->getAsStructureType() == IdStructType;
}

Side notes:

- I had to remove a convenience function from the TypesCompatibleExpr class.

int typesAreCompatible() const {return Type::typesAreCompatible(Type1,Type2);}

Which required a couple clients get a little more verbose...

-    Result = TCE->typesAreCompatible();
+    Result = Ctx.typesAreCompatible(TCE->getArgType1(), TCE->getArgType2());

Overall, I think this change also makes sense for a couple reasons...

1) Since ASTContext vends types, it makes sense for the type compatibility API to be there.
2) This allows the type compatibility predeciates to refer to data not strictly present in the AST (which I have found problematic on several occasions).

llvm-svn: 43009