radar 6507158.

llvm-svn: 109261

llvm-svn: 109258

fixes crashes on both valid and invalid code.  The diagnostic here could
potentially be improved, but it's good enough as-is.

llvm-svn: 109257

Finishes off radar 6507158.

llvm-svn: 109256

llvm-svn: 109254

llvm-svn: 109248

Dataflow solver: Don't overrwite the initial value of a block with top unless new values are available.  Patch by Simone Pellegrini!

llvm-svn: 109243

are not demanded. This often allows the anyext to be folded away.

llvm-svn: 109242

class is a templatized class that allows you to have a cleanup function called
on a data value of type T when the value is set or when the object goes
out of scope. It has support for very rudimentary invalid value detection that
can be enabled by using the appropriate constructor. 

Anyone with template experience that can see ways of improving this class
please let me know. The example code shows a few typical scenarios in which
I would like to use it. It is currently coded with simple type T values
in mind (integer file descriptors, pointers, etc), but I am sure some 
specialization might help out the class for more complex types.

There is a lot of documentation including examples in the CleanUp.h header 
file. 

llvm-svn: 109239

class citizen on the StopInfo class. 

llvm-svn: 109235

llvm-svn: 109234

them as such. Type::is(Signed|Unsigned|)IntegerType() now return false
for vector types, and new functions
has(Signed|Unsigned|)IntegerRepresentation() cover integer types and
vector-of-integer types. This fixes a bunch of latent bugs.

Patch from Anton Yartsev!

llvm-svn: 109229

ThreadCancel in Host::WillTerminate g_monitor_thread may be blocked on a call
to pthread_cond_wait (for example, line 640).  Now, by default, when a 
cancellation request is serviced g_monitor_thread will again own the mutex
guarding the condition variable it was waiting on.  This causes the call to 
SetValue in Host::WillTerminate to hit a deadlock.

The call to SetValue does not appear to be needed, so removing it solves
the issue.

Patch from Stephen Wilson.

llvm-svn: 109228

a segfault when calling pthread_cancel.  Also, sets m_read_thread_enabled if
the thread is actually spawned.

Patch from Stephen Wilson.

llvm-svn: 109227

llvm-svn: 109226

llvm-svn: 109225

llvm-svn: 109224

I'll try to track down why a bit later.

llvm-svn: 109223

llvm-svn: 109222

llvm-svn: 109221

is not a good idea. The codebase does not depend
in this any more, and it may introduce hidden
runtime cost. If you get compile errors, please
dereference your iterator before passing to cast<>
(and friends).

Also: please consider caching the result of
operator* and reusing that instead of dereferencing
many times.

llvm-svn: 109220

llvm-svn: 109219

llvm-svn: 109218

llvm-svn: 109217

llvm-svn: 109216

llvmc can be now compiled with llvm-gcc on Windows.

llvm-svn: 109215

Added Mach exception stop descriptions. The chunk of code I just added needs to be placed into a utility location so it can be used by ProcessMacOSX and debugserver.

llvm-svn: 109214

with an existing allocator.  The interesting use case of this
is that it allows "StringMap<whatever, BumpPtrAllocator&>" for
when you want to allocate out of a preexisting bump pointer
allocator owned by someone else.

llvm-svn: 109213

llvm-svn: 109212

llvm-svn: 109211

llvm-svn: 109210

to be executed by the inferior.  This required explicit support
from RecordingMemoryManager for finding the address range
belonging to a particular function.

Also fixed a bug in DisassemblerLLVM where the disassembler
assumed there was an AddressRange available even when it was
NULL.

llvm-svn: 109209

llvm-svn: 109208

llvm-svn: 109207

llvm-svn: 109206

llvm-svn: 109205

Add complete assembler support for FMA3 instructions, with descriptions and encodings taken from the AVX manual

llvm-svn: 109204

ASTUnit/CXTranslationUnit. We can't actually use this preamble yet,
however.

llvm-svn: 109202

SSE, so we can't return floating point values if this
is disabled.  Detect this error for clang.

With SSE1 only, f64 is a problem; it can be done, but
neither llvm-gcc nor clang has ever generated correct
code for it.  Since nobody noticed this I think it's
OK to treat it as an error for now.

This also handles SSE-sized vectors of floating point.
8207686, 8204109.

llvm-svn: 109201

llvm-svn: 109200