- I verified locally that the current dependency lists are identical.
 - This makes add_llvm_library_dependencies() a no-op. I'll remove it once this
   change passes the bots.

llvm-svn: 145355

Zap some completely ridiculous code.  There's probably a miscompile here, but I don't really want to try to write a testcase involving an invoke returning a pointer to a varargs function...

llvm-svn: 145347

Replaces r145318 with a more targetted fix for the relocation handling.

llvm-svn: 145346

Patch from Daniel Dunbar for future-proof against http://llvm.org/viewvc/llvm-project?view=rev&revision=145331.

llvm-svn: 145345

SCEV can't optimize undef in all cases, which is a separate issue from this test case.

llvm-svn: 145343

management of what allocations remain after an
expression finishes executing.  This saves around
2.5KiB per expression for simple expressions.

llvm-svn: 145342

llvm-svn: 145341

I suspect we could profitably remove/move some of the bullet points
under Clang here to the Clang notes in order to keep things clean on
both sides. Unless I hear objections I'll start doing that once folks
have read over the Clang notes a bit.

llvm-svn: 145340

Fix serialized diagnostics to handle FixIts that only remove text.  Fixes <rdar://problem/10473903>.

llvm-svn: 145339

 - This fixes some layering violations and matches how we handle the llvm-c lib,
   for example.

llvm-svn: 145338

formatting here a bit... mostly to my preferred bikeshed-blue.

llvm-svn: 145337

the release notes despite their awesomeness. If we had a thorough
discussion of the performance of Clang in 2.9 vs. 3.0, the first would
be more relevant, but we don't. The serialization stuff hopefully isn't
terribly visible to end users.

Objections to these omissions are of course welcome. =]

llvm-svn: 145336

extensions and one infrastructure feature addition that has a direct
impact on other projects which use Clang.

llvm-svn: 145335

llvm-svn: 145334

from the Objective-C experts, but the basic stuff is there now.

llvm-svn: 145333

attribute. This prevents the stack slot allocator from coming along and using a
stack which it thinks is available but isn't.
<rdar://problem/10492556>

llvm-svn: 145332

to the way we currently expect target selection to work -- clients are supposed
to have control over what targets are available.

llvm-svn: 145331

llvm-svn: 145330

llvm-svn: 145329

dependency information.

llvm-svn: 145328

(We should probably start doing some sort of autodetection like we do on Linux at some point.)

llvm-svn: 145326

llvm-svn: 145325

llvm-svn: 145324

 - Currently just tries to build a full library for i386/x86_64.

 - This is made substantially more complicated by the lack of a generalized way
   to check for/invoke cross compilers. For now, we just try and make it work
   for the matched arch, and rely on the host CC being Clang.

llvm-svn: 145322

llvm-svn: 145321

I think that's enough for my release notes.

llvm-svn: 145320

llvm-svn: 145319

rdar://10493453

llvm-svn: 145318

llvm-svn: 145317

llvm-svn: 145316

llvm-svn: 145315

in LLDB.

llvm-svn: 145314

llvm-svn: 145313

Correct the code generation for function arguments of vec3 types on x86_64 when they are greater than 128 bits. This was incorrectly coercing things like long3 into a double2.
Add test case.

llvm-svn: 145312

llvm-svn: 145311

return the module itself (in the module map) rather than returning the
umbrella header used to build the module. While doing this, make sure
that we're inferring modules for frameworks to build that module.

llvm-svn: 145310

accurate than my original notes were based on IRC conversations. Windows
folks, please edit as needed to make this closer to the truth if I've
still got it wrong.

llvm-svn: 145309

llvm-svn: 145308

add a bit to that section about the many bug-finding warnings that Clang
has grown since 2.9 as this is one of the more visible new additions.

llvm-svn: 145307

enough to merit space in the release notes.

llvm-svn: 145306