DW_OP_breg[0..31] to Dwarf.h.

Add "DW_" prefix to the llvm::dwarf::*String methods which did not
already have them in Dwarf.cpp.

llvm-svn: 106197

llvm-svn: 106196

didn't indicate violated invariants but that we weren't recovering well.

llvm-svn: 106195

TLVP:

movl _a@TLVP, %eax

Daniel: Please review if you get a chance.
llvm-svn: 106194

llvm-svn: 106193

llvm-svn: 106192

llvm-svn: 106191

llvm-svn: 106189

llvm-svn: 106188

llvm-svn: 106187

llvm-svn: 106186

be evaluated for 'bit' operators

llvm-svn: 106185

by inspecting the Store bindings instead of iterating over all the global variables
in a translation unit.  By looking at the store directly, we avoid cases where we cannot
directly load from the global variable, such as an array (which can result in an assertion failure)
and it also catches cases where we store stack addresses to non-scalar globals.
Also, but not iterating over all the globals in the translation unit, we maintain cache
locality, and the complexity of the checker becomes restricted to the complexity of the
analyzed function, and doesn't scale with the size of the translation unit.

This fixes PR 7383.

llvm-svn: 106184

the binding key instead of the region + offset.  It isn't clear if this is the best semantics, but most
clients will likely only care about simple bindings, or bindings to a particular variable.  We can
refine later if necessary.

llvm-svn: 106183

Correctly return early from BasicStoreManager::iterBindings() when the BindingsHandler returns false.

llvm-svn: 106182

llvm-svn: 106179

llvm-svn: 106178

"previous token" location at the end of the class definition. This
eliminates a badly-placed error + Fix-It when the ';' following a
class definition is missing. Fixes <rdar://problem/8066414>.

llvm-svn: 106175

The attribute class generation support is still somewhat limited.
See the accompanying clang commit for more details.

llvm-svn: 106174

llvm-svn: 106173

Currently, there are two effective changes:

 - Attr::Kind has been changed to attr::Kind, in a separate namespace
   rather than the Attr class. This is because the enumerator needs to
   be visible to parse.
 - The class definitions for the C++0x attributes other than aligned are
   generated by TableGen.

The specific classes generated by TableGen are controlled by an array in
TableGen (see the accompanying commit to the LLVM repository). I will be
expanding the amount of code generated as I develop the new attributes system
while initially keeping it confined to these attributes.

llvm-svn: 106172

llvm-svn: 106171

precise. Fixes PR7336.

llvm-svn: 106170

(or operator-function-id) as a template, but the context is actually
non-dependent or the current instantiation, allow us to use knowledge
of what kind of template it is, e.g., type template vs. function
template, for further syntactic disambiguation. This allows us to
parse properly in the presence of stray "template" keywords, which is
necessary in C++0x and it's good recovery in C++98/03.

llvm-svn: 106167

llvm-svn: 106164

specification.

llvm-svn: 106162

disambiguation keywords outside of templates in C++98/03. Previously,
the warning would fire when the associated nested-name-specifier was
not dependent, but that was a misreading of the C++98/03 standard:
now, we complain only when we're outside of any template.

llvm-svn: 106161

into the constructor for the LLVMDisassembler, resulting
in asserts.

llvm-svn: 106160

This is before LiveVariables anyway, where these kill flags are recalculated.

llvm-svn: 106157

now, so there's no need to disable them.

llvm-svn: 106155

llvm-svn: 106154

LiveVariableAnalysis was a bit picky about a register only being redefined once,
but that really isn't necessary.

Here is an example of chained INSERT_SUBREGs that we can handle now:

68      %reg1040<def> = INSERT_SUBREG %reg1040, %reg1028<kill>, 14
                register: %reg1040 +[70,134:0)
76      %reg1040<def> = INSERT_SUBREG %reg1040, %reg1029<kill>, 13
                register: %reg1040 replace range with [70,78:1) RESULT: %reg1040,0.000000e+00 = [70,78:1)[78,134:0)  0@78-(134) 1@70-(78)
84      %reg1040<def> = INSERT_SUBREG %reg1040, %reg1030<kill>, 12
                register: %reg1040 replace range with [78,86:2) RESULT: %reg1040,0.000000e+00 = [70,78:1)[78,86:2)[86,134:0)  0@86-(134) 1@70-(78) 2@78-(86)
92      %reg1040<def> = INSERT_SUBREG %reg1040, %reg1031<kill>, 11
                register: %reg1040 replace range with [86,94:3) RESULT: %reg1040,0.000000e+00 = [70,78:1)[78,86:2)[86,94:3)[94,134:0)  0@94-(134) 1@70-(78) 2@78-(86) 3@86-(94)

rdar://problem/8096390

llvm-svn: 106152

llvm-svn: 106151

when iterating through instructions. Yet more work for rdar://7797940

llvm-svn: 106149

template name that refers to such a parameter. It's amazing that this
problem didn't surface earlier. Fixes PR7387.

llvm-svn: 106147

The test should also likely have some FileCheck bits to validate the
output(?).

llvm-svn: 106146

llvm-svn: 106144

MC/Mach-O: Rewrite atom association to be a final pass we do in Finish(), instead of tracking as part of emission.
 - This allows sharing more code with the MCObjectStreamer.

llvm-svn: 106143

llvm-svn: 106142

llvm-svn: 106141