of the code generator shouldn't care what object format a target
uses.

llvm-svn: 95124

llvm-svn: 95123

llvm-svn: 95122

llvm-svn: 95121

llvm-svn: 95120

llvm-svn: 95119

yesterday.  This eliminates possible confusion
about what exactly in this directory; the name
is still short, though.

llvm-svn: 95118

WHAT!?!

It turns out that Type::isPromotableIntegerType() was not considering
enumeration types to be promotable, so we would never do the
promotion despite having properly computed the promotion type when the
enum was defined. Various operations on values of enum type just
"worked" because we could still compute the integer rank of an enum
type; the oddity, however, is that operations such as "add an enum and
an unsigned" would often have an enum result type (!). The bug
actually showed up as a spurious -Wformat diagnostic
(<rdar://problem/7595366>), but in theory it could cause miscompiles.

In this commit:
  - Enum types with a promotion type of "int" or "unsigned int" are
  promotable.
  - Tweaked the computation of promotable types for enums
  - For all of the ABIs, treat enum types the same way as their
  underlying types (*not* their promotion types) for argument passing
  and return values
  - Extend the ABI tester with support for enumeration types

llvm-svn: 95117

Set the correct vtable pointers _before_ generating code for any member initializers. Fixes about ~2000 clang/LLVM tests in the clang-on-clang build.

llvm-svn: 95116

llvm-svn: 95114

a layering violation from MC -> Target.

llvm-svn: 95113

llvm-svn: 95112

llvm-svn: 95111

llvm-svn: 95110

the one used by the JIT.  Remove all forms of
addPassesToEmitFileFinish except the one used by the static
code generator.  Inline the remaining version of
addPassesToEmitFileFinish into its only caller.

llvm-svn: 95109

llvm-svn: 95108

This test case is different subset of the full auto generated test case, and a
larger subset that is in x86_32-bit.s (that set will encode correctly).  These
instructions can pass though llvm-mc as it were a logical cat(1) and then
reassemble to the same instruction.  It is useful as we bring up the parser and
matcher so we don't break things that currently work.

llvm-svn: 95107

llvm-svn: 95106

llvm-svn: 95105

llvm-svn: 95104

buildbot failure.

llvm-svn: 95103

the -print-emitted-asm option.  The JIT shouldn't have to pull
in the asmprinter.

llvm-svn: 95100

Check for redefinitions in MergeVarDecl. This finds redefinitions of globals without an initializer in C++ and thus fixes PR5451.

llvm-svn: 95098

Fixes radar 7589414.

llvm-svn: 95097

llvm-svn: 95096

llvm-svn: 95095

type qualifiers and type specifiers in any order.   For example,
this is valid: struct x {...} typedef y;

This fixes PR6208.

llvm-svn: 95094

this is still a popular thing to do.

llvm-svn: 95093

llvm-svn: 95086

unused variable warning.

llvm-svn: 95085

llvm-svn: 95079

magnitude clearer.

llvm-svn: 95078

Eliminates a lot of spurious global initializers, fixing PR6205.

llvm-svn: 95077

llvm-svn: 95076

llvm-svn: 95075

llvm-svn: 95074

parameter to record whether changes actually happened.

llvm-svn: 95073

UnresolvedMemberExpr and employ it in a few places where it's useful.

llvm-svn: 95072

dyncast is just due to \r\n newline interaction w/ regexps. The remap-load.c
failure is a bit stranger (the end of the extent is on the next line), but I
don't care to investigate.

llvm-svn: 95071

lookup is that if the lookup key is contained in the key, we return the data.

llvm-svn: 95070