llvm-svn: 111537

llvm-svn: 111536

The Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01
implements parts of C++0x based on the draft standard. An old version of
the draft had a bug that makes std::pair<T1*, T2*>(something, 0) fail to
compile. This is because the template<class U, class V> pair(U&& x, V&& y)
constructor is selected, even though it later fails to implicitly convert
U and V to frist_type and second_type.

This has been fixed in n3090, but it seems that Microsoft is not going to
update msvc.

llvm-svn: 111535

llvm-svn: 111534

rdar://8277890

llvm-svn: 111533

llvm-svn: 111532

llvm-svn: 111531

llvm-svn: 111530

changes.

llvm-svn: 111529

llvm-svn: 111528

and correctness regressions.

llvm-svn: 111527

conversion a second time for a conversion candidate (with the real
acting context), because the only problems we would find are access or
ambiguity issues that won't be diagnosed until we pick this
candidate. Add a test case to prove it to myself.

llvm-svn: 111526

llvm-svn: 111525

llvm-svn: 111524

bonkers sometimes.

llvm-svn: 111523

conversion functions as if their acting context were the class that
we're converting from (the implicit object argument's
type). Retroactively tweaking the implicit conversion sequence, as we
were trying to do before, breaks the invariants of that implicit
conversion sequence (e.g., the types and conversions don't match
up). Fixes <rdar://problem/8018274>.

llvm-svn: 111520

Include a proper citation for the wacky hijinks involving conversion functions and the implicit object parameter type. No functionality change.

llvm-svn: 111519

llvm-svn: 111518

llvm-svn: 111517

llvm-svn: 111516

llvm-svn: 111515

compilation with MSVC.  Note that on other platforms, the operator delete in
question is never used because we compile with -fno-exceptions.

llvm-svn: 111514

cfe-dev, fixes an error compiling with MSVC.  Using a StringRef here doesn't
look safe in any case.

llvm-svn: 111513

for incomplete enum types.  An incomplete enum can't really be treated as
an "integral or enumeration" type, and the incorrect treatment leads to
bad behavior for many callers.

This makes isIntegralOrEnumerationType equivalent to isIntegerType; I think
we should globally replace the latter with the former; thoughts?

llvm-svn: 111512

support for the rest of AltiVec functions with bool/pixel arguments and return values (except predicates)

llvm-svn: 111511

llvm-svn: 111510

support for vec_perm and all dependent functions (vec_mergeh, vec_mergel, vec_pack, vec_sld, vec_splat) with bool/pixel arguments and return values

llvm-svn: 111509

base registers were required. This will allow for slightly better packing
of the locals when alignment padding is necessary after callee saved registers.

llvm-svn: 111508

active C++ ABI as a raw string, we store it as an enum. This should improve
performance somewhat.

And yes, this time, I started from a clean build directory, and
all the tests passed. :)

llvm-svn: 111507

llvm-svn: 111504

llvm-svn: 111500

depending on the number of virtual registers appear to have all been handled
now.

llvm-svn: 111499

llvm-svn: 111498

llvm-svn: 111497

call and jumps.

llvm-svn: 111496

of the two.

llvm-svn: 111495

llvm-svn: 111494

All it does right now is add space for two vtable pointers instead of one
when a class has both virtual methods and virtual bases. This is a requirement
of the Microsoft ABI, since it has separate vtables for methods and bases. Other
stuff will come up over time, but we'll cross those bridges when we get to
them.

llvm-svn: 111493

Add warning for functions/blocks that have attribute 'noreturn' but return a non-void result. (<rdar://problem/7562925>)

llvm-svn: 111492

HandleCommonNoReturnAttr() now only has a single caller.  Move that logic to HandleAnalyzerNoReturnAttr.

llvm-svn: 111491