llvm-svn: 72558

llvm-svn: 72557

decoding. Essentially, they both map to the same column in the "opcode
extensions for one- and two-byte opcodes" table in the x86 manual. The RawFrm
complicates decoding this.

Instead, use opcode 0x01, prefix 0x01, and form MRM1r. Then have the code
emitter special case these, a la [SML]FENCE.

llvm-svn: 72556

specifier resulted in the creation of a new TagDecl node, which
happens either when the tag specifier was a definition or when the tag
specifier was the first declaration of that tag type. This information
has several uses, the first of which is implemented in this commit:

  1) In C++, one is not allowed to define tag types within a type
  specifier (e.g., static_cast<struct S { int x; } *>(0) is
  ill-formed) or within the result or parameter types of a
  function. We now diagnose this.

  2) We can extend DeclGroups to contain information about any tags
  that are declared/defined within the declaration specifiers of a
  variable, e.g.,

    struct Point { int x, y, z; } p;

  This will help improve AST printing and template instantiation,
  among other things.

  3) For C99, we can keep track of whether a tag type is defined
  within the type of a parameter, to properly cope with cases like,
  e.g.,

    int bar(struct T2 { int x; } y) {
      struct T2 z;
    }

  We can also do similar things wherever there is a type specifier,
  e.g., to keep track of where the definition of S occurs in this
  legal C99 code:

    (struct S { int x, y; } *)0

  

llvm-svn: 72555

getUnqualifiedType() doesn't strip off all qualifiers for non-canonical 
types.

llvm-svn: 72552

-parallel, instead of always using 2).

llvm-svn: 72551

llvm-svn: 72539

llvm-svn: 72538

This patch removes some special cases for opcodes and does a bit of 
cleanup.

llvm-svn: 72536

llvm-svn: 72535

llvm-svn: 72534

llvm-svn: 72533

sending data to the server.
 - Otherwise if the server connection fails the external script never runs.

Also, create content before initiating connection to try and decrease time we
are connected to llvm.org.

llvm-svn: 72532

llvm-svn: 72531

failure during llvm-gcc bootstrap:

Assertion failed: (!Tmp2.getNode() && "Can't legalize BR_CC with legal condition!"), function ExpandNode, file /Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmCore.roots/llvmCore~obj/src/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp, line 2923.
/Volumes/Sandbox/Buildbot/llvm/full-llvm/build/llvmgcc42.roots/llvmgcc42~obj/src/gcc/libgcc2.c:1727: internal compiler error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.

llvm-svn: 72530

llvm-svn: 72529

llvm-svn: 72528

clang -> clang-cc to be less confusing.

llvm-svn: 72527

given DeclContext is dependent on type parameters. Use this to
properly determine whether a TagDecl is dependent; previously, we were
missing the case where the TagDecl is a local class of a member
function of a class template (phew!).

Also, make sure that, when we instantiate declarations within a member
function of a class template (or a function template, eventually),
that we add those declarations to the "instantiated locals" map so
that they can be found when instantiating declaration references.

Unfortunately, I was not able to write a useful test for this change,
although the assert() that fires when uncommenting the FIXME'd line in
test/SemaTemplate/instantiate-declref.cpp tells the "experienced user"
that we're now doing the right thing.

llvm-svn: 72526

llvm-svn: 72521

llvm-svn: 72520

diagnostic to include the full instantiation location for the
invalid paste.  For:

#define foo(a, b)  a ## b
#define bar(x) foo(x, ])
bar(a)
bar(zdy)

Instead of:

t.c:3:22: error: pasting formed 'a]', an invalid preprocessing token
#define foo(a, b)  a ## b
                     ^
t.c:3:22: error: pasting formed 'zdy]', an invalid preprocessing token

we now produce:

t.c:7:1: error: pasting formed 'a]', an invalid preprocessing token
bar(a)
^
t.c:4:16: note: instantiated from:
#define bar(x) foo(x, ])
               ^
t.c:3:22: note: instantiated from:
#define foo(a, b)  a ## b
                     ^
t.c:8:1: error: pasting formed 'zdy]', an invalid preprocessing token
bar(zdy)
^
t.c:4:16: note: instantiated from:
#define bar(x) foo(x, ])
               ^
t.c:3:22: note: instantiated from:
#define foo(a, b)  a ## b
                     ^

llvm-svn: 72519

llvm-svn: 72517

llvm-svn: 72516

This is basically the end of this series of patches for LegalizeDAG; the 
remaining special cases can't be removed without more infrastructure 
work.  There's a FIXME for each relevant opcode near the beginning of
SelectionDAGLegalize::LegalizeOp.

llvm-svn: 72514

is actually legal.  Part of LegalizeDAG cleanups.

llvm-svn: 72513

empty SmallVector.

llvm-svn: 72512

some special cases are necessary.

llvm-svn: 72511

list in Attributes.h. It also reorders the CPPBackend list to match so that
it's easier to see that it's complete.

llvm-svn: 72510

llvm-svn: 72509

the Intel manual (screenshot) says it should be 0b11110110 (f6).  The existing
encoding causes a disassembly conflict with MMX_PAVGBrm, which really should be
0f e0."

Patch by Sean Callanan!

llvm-svn: 72508

Added optimization that narrow load / op / store and the 'op' is a bit twiddling instruction and its second operand is an immediate. If bits that are touched by 'op' can be done with a narrower instruction, reduce the width of the load and store as well. This happens a lot with bitfield manipulation code.
e.g.
orl     $65536, 8(%rax)
=>
orb     $1, 10(%rax)

Since narrowing is not always a win, e.g. i32 -> i16 is a loss on x86, dag combiner consults with the target before performing the optimization.

llvm-svn: 72507

llvm-svn: 72506

llvm-svn: 72504

llvm-svn: 72503

parser. Rather than placing all of the delayed member function
declarations and inline definitions into a single bucket corresponding
to the top-level class, we instead mirror the nesting structure of the
nested classes and place the delayed member functions into their
appropriate place. Then, when we actually parse the delayed member
function declarations, set up the scope stack the same way as it was
when we originally saw the declaration, so that we can find, e.g.,
template parameters that are in scope.

llvm-svn: 72502

section.

llvm-svn: 72501

reflect that.

llvm-svn: 72500

behavior is more likely to be confusing than useful.

llvm-svn: 72499

Reintroduce the home for exception specs, and make Sema fill it. However, keep the spec out of the canonical type this time. Net effect is currently nothing, because the spec isn't checked anywhere.

llvm-svn: 72498