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

definitions to also include tag declarations. Fixes PR8151.

llvm-svn: 131102

hasTrivialDefaultConstructor() really really means it now.

Also implement a fun standards bug regarding aggregates. Doug, if you'd
like, I can un-implement that bug if you think it is truly a defect.

The bug is that non-special-member constructors are never considered
user-provided, so the following is an aggregate:

struct foo {
  foo(int);
};

It's kind of bad, but the solution isn't obvious - should

struct foo {
  foo (int) = delete;
};

be an aggregate or not?

Lastly, add a missing initialization to FunctionDecl.

llvm-svn: 131101

for http://llvm.org/viewvc/llvm-project?rev=131089&view=rev.

llvm-svn: 131100

also consider whether any of the parameter types (as written, prior to
decay) are dependent. Fixes PR9880 and <rdar://problem/9408413>.

llvm-svn: 131099

before we try to.

Patch by Patrick Walton!

llvm-svn: 131098

llvm-svn: 131097