llvm-svn: 131151

llvm-svn: 131149

DwarfRequiresRelocationForSectionOffset as this is not specific to StmtList.

llvm-svn: 131148

Wait, what?

So, we run Clang (and LLVM) tests in an environment where the md5sum of the
input files becomes a component of the path. When testing the preprocessor,
the path becomes part of the output (in line directives). In this test, we
were grepping for the absence of "abc" in the output. When the stars aligned
properly, the md5sum component of the path contained "abc" and the test
failed. Oops.

llvm-svn: 131147

llvm-svn: 131146

looked up.  Queries for global types were made
too specific -- including the current module
and compile unit in the query was limiting the
search when we wanted a truly global search.

llvm-svn: 131145

Add a utility function get_registers(frame, kind) to get the registers of a given frame and of a given kind.
Also add three convenience functions get_GPRs(frame), get_FPRs(frame), and get_ESRs(frame) to get the general
purpose registers, the floating point registers, and the exception state registers.

Add TestRegistersIterator.py to test these added functions of lldbutil.py.

llvm-svn: 131144

I've edited one diagnostic which would print "copy constructor" for copy
constructors and "constructor" for any other constructor. If anyone is
extremely enamored with this, it can be reinstated with a simple boolean
flag rather than calling getSpecialMember, which is inappropriate.

llvm-svn: 131143

llvm-svn: 131142

Elide __label__ declarations from the CFG.  This resolves a crash in CFGRecStmtDeclVisitor (crash in static analyzer).

llvm-svn: 131141

this clang will use .debug_frame in, for example,
clang -g -c -m32 test.c
This matches gcc's behaviour. It looks like .debug_frame is a bit bigger
than .eh_frame, but has the big advantage of not being allocated.

llvm-svn: 131140

cut and paste.

llvm-svn: 131139

the semantic context referenced by the nested-name-specifier rather
than the syntactic form of the nested-name-specifier. The previous
incarnation was based on my complete misunderstanding of C++
[temp.expl.spec]. The latest C++0x working draft clarifies the
requirements here, and this rewrite is intended to follow that.

Along the way, improve source location information in the
diagnostics. For example, if we report that a specific type needs or
doesn't need a 'template<>' header, we dig out that type in the
nested-name-specifier and highlight its range.

Fixes: PR5907, PR9421, PR8277, PR8708, PR9482, PR9668, PR9877, and
<rdar://problem/9135379>.

llvm-svn: 131138

DWARF stuff also gets fixed up by ELFARMAsmBackend::ApplyFixup(),
but the offset is not guaranteed to be mod 4 == 0 as in text/data. 

llvm-svn: 131137

Ambiguous sub-register index compositions are OK as long as the backend writer
knows what he is doing.

llvm-svn: 131134

The previous invalidation missed the alias interference caches.

Also add a stats counter for the number of repaired ranges.

llvm-svn: 131133

llvm-svn: 131132

llvm-svn: 131129

Patch by Dan Bailey

llvm-svn: 131128

llvm-svn: 131127

llvm-svn: 131126

one of the sections is created.

llvm-svn: 131124

Patch by Wei-Ren Chen

llvm-svn: 131123

llvm-svn: 131121

llvm-svn: 131120

llvm-svn: 131119

llvm-svn: 131118

llvm-svn: 131117

llvm-svn: 131116

Focus is on default constructors for the time being. Currently the
exception specification and prototype are processed correctly. Codegen
might work but in all likelihood doesn't.

Note that due to an error, out-of-line defaulting of member functions is
currently impossible. It will continue to that until I muster up the
courage to admit that I secretly pray to epimetheus and that I need to
rework the way default gets from Parse -> Sema.

llvm-svn: 131115

reflect our new, more accurate AST.

llvm-svn: 131114

Also some -fdelayed-template-parsing test refactoring.

llvm-svn: 131113

llvm-svn: 131112

llvm-svn: 131111

Make sure writing asynchronous output only backs up
& overwrites prompt if the IOChannel input reader is the top
input reader.

llvm-svn: 131110

unions. Fixes PR8326.

llvm-svn: 131109

llvm-svn: 131108

llvm-svn: 131106

treated as being permanently resident in target
memory.  In fact, since the expression's stack frame
is deleted and potentially re-used after the
expression completes, the variables need to be treated
as being freeze-dried.

llvm-svn: 131104

structs (impacts 32-bit only though).

llvm-svn: 131103