llvm-svn: 145530

llvm-svn: 145528

to find Objective-C class types by looking in the
symbol tables for the individual object files.

I did this as follows:

- I added code to SymbolFileSymtab that vends
  Clang types for symbols matching the pattern
  "_OBJC_CLASS_$_NSMyClassName," making them
  appear as Objective-C classes.  This only occurs
  in modules that do not have debug information,
  since otherwise SymbolFileDWARF would be in
  charge of looking up types.

- I made a new SymbolVendor subclass for the
  Apple Objective-C runtime that is in charge of
  making global lookups of Objective-C types.  It
  currently just sends out type lookup requests to
  the appropriate SymbolFiles, but in the future we
  will probably extend it to query the runtime more
  completely.

I also modified a testcase whose behavior is changed
by the fact that we now actually return an Objective-C
type for __NSCFString.

llvm-svn: 145526

remaining FMA4 instructions and intrinsics with tests.

llvm-svn: 145525

Per an offline conversation with John McCall, have StmtPrinter actually print out the source expression for OpaqueValueExpr.

llvm-svn: 145524

Make GlobalMerge honor the preferred alignment on globals without an explicitly specified alignment.

<rdar://problem/10497732>.

llvm-svn: 145523

llvm-svn: 145522

llvm-svn: 145521

Don't run -Wunreachable-code on template instantiations.  Different instantiations may produce different unreachable code results, and it is very difficult for us to prove that ALL instantiations of a template have specific unreachable code.  If we come up with a better solution, then we can revisit this, but this approach will at least greatly reduce the noise of this warning for code that makes use of templates.

llvm-svn: 145520

When I did this before it broke a buildbot that was testing that target, but
we've removed that buildbot now.

llvm-svn: 145519

llvm-svn: 145518

llvm-svn: 145517

llvm-svn: 145516

llvm-svn: 145515

llvm-svn: 145514

llvm-svn: 145512

a symbol, were weren't showing the "<module>`<symbol>" header.

llvm-svn: 145511

llvm-svn: 145510

it to GNU assembler. In addition, change function getMipsArchFromCPU() so that
it can be reused in ConstructJob(). 

Patch by Simon Atanasyan.

llvm-svn: 145509

llvm-svn: 145508

Fix the breakage by properly setting the result status before returning.

llvm-svn: 145507

llvm-svn: 145506

llvm-svn: 145505

llvm-svn: 145504

callback client to suggest an alternative search path and after we
complain when the included file can't be found. The former can't be
tested in isolation, the latter doesn't actually matter (because we
won't make a module suggestion if no header is available). However,
the flow is better this way.

llvm-svn: 145502

llvm-svn: 145501

an #include/#import as a module import.

llvm-svn: 145500

llvm-svn: 145498

submodules. This information will eventually be used for name hiding
when dealing with submodules. For now, we only use it to ensure that
the module "key" returned when loading a module will always be a
module (rather than occasionally being a FileEntry).

llvm-svn: 145497

llvm-svn: 145496

llvm-svn: 145495

While at it remove the barcelona/instanbul/shanghai subtargets, they're
unsupported by GCC and look pretty broken.

llvm-svn: 145494

llvm-svn: 145493

llvm-svn: 145492

raw_ostream::write_escaped. Thanks, Benjamin!

llvm-svn: 145491

llvm-svn: 145490

llvm-svn: 145489

X86: PerformOrCombine introduced a vselect node with a wrong order of operands. This bug was introduced when a dedicated blend sdnode was replaced with the vselect node (in 139479).

llvm-svn: 145488

llvm-svn: 145487

-fplugin-arg-dragonegg-enable-gcc-optzns, though it usually isn't
a win.

llvm-svn: 145486