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

into some cleanup I have been wanting to do when reading/writing registers.
Previously all RegisterContext subclasses would need to implement:

virtual bool
ReadRegisterBytes (uint32_t reg, DataExtractor &data);

virtual bool
WriteRegisterBytes (uint32_t reg, DataExtractor &data, uint32_t data_offset = 0);

There is now a new class specifically designed to hold register values: 
        lldb_private::RegisterValue
        
The new register context calls that subclasses must implement are:

virtual bool
ReadRegister (const RegisterInfo *reg_info, RegisterValue &reg_value) = 0;

virtual bool
WriteRegister (const RegisterInfo *reg_info, const RegisterValue &reg_value) = 0;

The RegisterValue class must be big enough to handle any register value. The
class contains an enumeration for the value type, and then a union for the 
data value. Any integer/float values are stored directly in an appropriate
host integer/float. Anything bigger is stored in a byte buffer that has a length
and byte order. The RegisterValue class also knows how to copy register value
bytes into in a buffer with a specified byte order which can be used to write
the register value down into memory, and this does the right thing when not
all bytes from the register values are needed (getting a uint8 from a uint32
register value..). 

All RegiterContext and other sources have been switched over to using the new
regiter value class.

llvm-svn: 131096

llvm-svn: 131094

Patch by Evan Cheng.

llvm-svn: 131093

llvm-svn: 131090

Fix the wrong error message for "platform process info", i.e., with no pid(s) specified for the command.

llvm-svn: 131089

llvm-svn: 131088

modify the semantics slightly to accomodate default constructors (I
hope).

llvm-svn: 131087

Patch by Liu <proljc@gmail.com>!

llvm-svn: 131086

llvm-svn: 131085

when POSIXLY_COMPLIANT is set.
 - Patch by Dave Vasilevsky!

llvm-svn: 131084

llvm-svn: 131082

being returned for both the PC and FP.

llvm-svn: 131081

rdar://problem/9391966

llvm-svn: 131080

llvm-svn: 131079

llvm-svn: 131078

llvm-svn: 131077

Necessary to parse MFC code.

llvm-svn: 131076

llvm-svn: 131075

llvm-svn: 131074

It can happen that a live debug variable is the last use of a sub-register, and
the register allocator will pick a larger register class for the virtual
register.  If the allocated register doesn't support the sub-register index,
just use %noreg for the debug variables instead of asserting.

In PR9872, a debug variable ends up in the sub_8bit_hi part of a GR32_ABCD
register. The register is split and one part is inflated to GR32 and assigned
%ESI because there are no more normal uses of sub_8bit_hi.

Since %ESI doesn't have that sub-register, substPhysReg asserted. Now it will
simply insert a %noreg instead, and the debug variable will be marked
unavailable in that range.

We don't currently have a way of saying: !"value" is in bits 8-15 of %ESI, I
don't know if DWARF even supports that.

llvm-svn: 131073

llvm-svn: 131072

"b + ((a < b) ? 1 : 0)" compiles into
	cmpl	%esi, %edi
	adcl	$0, %esi
instead of
	cmpl	%esi, %edi
	sbbl	%eax, %eax
	andl	$1, %eax
	addl	%esi, %eax

This saves a register, a false dependency on %eax
(Intel's CPUs still don't ignore it) and it's shorter.

llvm-svn: 131070

of a universal binary and 'rax' register is available when launching the x86_64 slice.

rdar://problem/9403437

llvm-svn: 131069

complete destructors for abstract classes unless the destructor is virtual
and thus needs to be in the vtable.

llvm-svn: 131068

the smaller encoding and this cuts 270336 bytes from a release version of
clang and 1246272 bytes from a debug build.

llvm-svn: 131067

llvm-svn: 131066

bit by allowing __weak and __strong to be added/dropped as part of
implicit conversions (qualification conversions in C++). A little
history: GCC lets one add/remove/change GC qualifiers just about
anywhere, implicitly. Clang did roughly the same before, but we
recently normalized the semantics of qualifiers across the board to
get a semantics that we could reason about (yay). Unfortunately, this
tightened the screws a bit too much for GC qualifiers, where it's
common to add/remove these qualifiers at will.

Overall, we're still in better shape than we were before: we don't
permit directly changing the GC qualifier (e.g., __weak -> __strong),
so type safety is improved. More importantly, we're internally
consistent in our handling of qualifiers, and the logic that allows
adding/removing GC qualifiers (but not adding/removing address
spaces!) only touches two obvious places.

Fixes <rdar://problem/9402499>.

llvm-svn: 131065

a new "QLaunchArch:<arch-name>" where <arch-name> is the architecture name.
This allows us to remotely launch a debugserver and then set the architecture
for the binary we will launch.

llvm-svn: 131064

they are treated as pointers of type (void*).  This
allows reading of environ, for instance.

llvm-svn: 131063

compiling Operator.h with gcc 4.6 in C++0x mode.

llvm-svn: 131062

function and if not return an error.

llvm-svn: 131061

type, so long as it is known to have a constant initializer and the
class type is a POD class. Fixes <rdar://problem/9306265>.

llvm-svn: 131060