This patch allows llvm to recognize that a 64 bit object file is being produced
and that the subsequently generated ELF header has the correct information.

The test case checks for both big and little endian flavors.

Patch by Jack Carter.

llvm-svn: 153889

llvm-svn: 153888

The diagnostic message correctly informs the user that they have omitted the
'class' keyword, but neither suggests this insertion as a fixit, nor attempts
to recover as if they had provided the keyword.

This fixes the recovery, adds the fixit, and adds a separate diagnostic and
corresponding replacement fixit for cases where the user wrote 'struct' or
'typename' instead of 'class' (suggested by Richard Smith as a possible common
mistake).

I'm not sure the diagnostic message for either the original or new cases feel
very Clang-esque, so I'm open to suggestions there. The fixit hints make it
fairly easy to see what's required, though.

llvm-svn: 153887

llvm-svn: 153886

llvm-svn: 153885

not by canonical decl. This only matters for sizeof...(Pack) expressions; in
all other cases, we'd profile it as a type instead.

llvm-svn: 153884

move constructor/move assignment operator are not declared, rather than being
defined as deleted, so move operations on the derived class fall back to
copying rather than moving.

If a move operation on the derived class is explicitly defaulted, the
unmovable subobject will be copied instead of being moved.

llvm-svn: 153883

llvm-svn: 153882

llvm-svn: 153881

llvm-svn: 153880

http://llvm.org/bugs/show_bug.cgi?id=12343

We have not trivial way for splitting edges that are goes from indirect branch. We can do it with some tricks, but it should be additionally discussed. And it is still dangerous due to difficulty of indirect branches controlling.

Fix forbids this case for unswitching.

llvm-svn: 153879

llvm-svn: 153878

objective-c's fragile abi, Use -rewrite-objc for translating 
objective-c's modern abi.  // rdar://11143173

llvm-svn: 153877

llvm-svn: 153876

llvm-svn: 153875

llvm-svn: 153874

Fix test for default constructor of discrete_distribution.  This partially addresses http://llvm.org/bugs/show_bug.cgi?id=12436.

llvm-svn: 153873

llvm-svn: 153872

llvm-svn: 153871

reflected in the LLVM IR (as a declare or something), then treat it like a data
object.

N.B. This isn't 100% correct. The ASM parser should supply more information so
that we know what type of object it is, and what attributes it should have.

llvm-svn: 153870

This way we can get AVX v-prefixed instructions tail merged with the normal insns.

llvm-svn: 153869

with some archs, tweak the way we update PATH to fix that.

llvm-svn: 153868

All implementations used the same code.

llvm-svn: 153866

Reorder fields in MatchEntry and OperandMatchEntry to reduce padding. A bit tricky due to the target specific sizes for some of the fields so the ordering is only optimal for the targets in the tree.

llvm-svn: 153865

Do not try to optimize swizzles of shuffles if the source shuffle has more than
a single user, except when the source shuffle is also a swizzle.

llvm-svn: 153864

Remove getInstructionName from MCInstPrinter implementations in favor of using the instruction name table from MCInstrInfo. Reduces static data in the InstPrinter implementations.

llvm-svn: 153863

Patch by Jeremy Huddleston!

llvm-svn: 153862

llvm-svn: 153861

Make MCInstrInfo available to the MCInstPrinter. This will be used to remove getInstructionName and the static data it contains since the same tables are already in MCInstrInfo.

llvm-svn: 153860

definition for it. In that case, we want to wait for the potential definition
before we create a symbol for it.

llvm-svn: 153859

dependent contexts.

llvm-svn: 153858

llvm-svn: 153857

This is an initial commit of constexpr support as proposed by Richard Smith.  This by no means completes constexpr support.  Indeed, it hardly scratches the surface.  All it does is lay the foundation in <__config> and changes those few places in the library that are already using that foundation.

llvm-svn: 153856

I believe tuple is still under development in the standard.  Daniel Krugler is/will be making convincing arguments that a modified form of LWG 2051 (currently NAD Future) is easily acheivable and desirable.  He has demonstrated that a tuple<T...> where all of the T are implicitly convertible from U... should have a tuple constructor that is also implicit, instead of explicit.  This would support the use cases in LWG 2051 while not undermining T... with explicit conversions from U....  This check-in is an experimental implementation of Daniel's work.  I believe this work to be mature enough to warrant inclusion into libc++.  If anyone sees real-world problems that this check in causes, please let me know and I will revert it, and provide the feedback to the LWG.

llvm-svn: 153855

llvm-gcc doesn't handle --serialize-diagnostics so when compiling i386
kernel/kext code with -Werror, you get an error about that option being
unused.  Claim the argument to prevent this from breaking builds.
<rdar://problem/11161933>

llvm-svn: 153854

rather than a bitfield, a great suggestion by Chris during code review.

There is still quite a bit of cruft in the interface, but that requires
sorting out some awkward uses of the cost inside the actual inliner.

No functionality changed intended here.

llvm-svn: 153853

llvm-svn: 153852

llvm-svn: 153851

llvm-svn: 153850

llvm-svn: 153849