at all of the operands. Previously it was skipping over implicit operands which
cause infinite looping when the two-address pass try to reschedule a
two-address instruction below the kill of tied operand.

I'm unable to come up with a reasonably sized test case.
rdar://13747577

llvm-svn: 180906

llvm-svn: 180905

It is unfortunate that we have to mark these exceptions in multiple places.
This was already in CallEvent. I suppose it does let us be more precise
about saying /which/ arguments have their retain counts invalidated -- the
connection's is still valid even though the context object's isn't -- but
we're not tracking the retain count of XPC objects anyway.

<rdar://problem/13783514>

llvm-svn: 180904

llvm-svn: 180903

llvm-svn: 180902

llvm-svn: 180901

The patch allows Windows users to launch scan-build without any additional preparations in the same way as it described in http://clang-analyzer.llvm.org/scan-build.html. The only thing that should be done to make scan-build work from an arbitrary location is to add scan-build folder to the PATH environment variable.

llvm-svn: 180900

support operands with vector types, it now reports
that it cannot interpret expressions that use
vector types.  They get sent to the JIT instead.

<rdar://problem/13733651>

llvm-svn: 180899

llvm-svn: 180898

No functionality changes.

llvm-svn: 180897

Return zero when we don't support the byte size. Previously is we were asked to read 3, 5, 6, or 7 byte integers, we would set the error, but still return that we read that number of bytes without populating the scalar.

llvm-svn: 180896

in debug information more aggressive.  Emitting
classes containing these methods causes crashes in
Clang when dealing with complex code bases.

<rdar://problem/12640887>

llvm-svn: 180895

Previously, this was scattered across Environment (literal expressions),
ExprEngine (default arguments), and RegionStore (global constants). The
former special-cased several kinds of simple constant expressions, while
the latter two deferred to the AST's constant evaluator.

Now, these are all unified as SValBuilder::getConstantVal(). To keep
Environment fast, the special cases for simple constant expressions have
been left in, but the main benefits are that (a) unusual constants like
ObjCStringLiterals now work as default arguments and global constant
initializers, and (b) we're not duplicating code between ExprEngine and
RegionStore.

This actually caught a bug in our test suite, which is awesome: we stop
tracking allocated memory if it's passed as an argument along with some
kind of callback, but not if the callback is 0. We were testing this in
a case where the callback parameter had a default value, but that value
was 0. After this change, the analyzer now (correctly) flags that as a
leak!

<rdar://problem/13773117>

llvm-svn: 180894

CodeModel: It's now possible to create an MCJIT instance with any CodeModel you like.  Previously it was only possible to 
create an MCJIT that used CodeModel::JITDefault.

EnableFastISel: It's now possible to turn on the fast instruction selector.

The CodeModel option required some trickery.  The problem is that previously, we were ensuring future binary compatibility in 
the MCJITCompilerOptions by mandating that the user bzero's the options struct and passes the sizeof() that he saw; the 
bindings then bzero the remaining bits.  This works great but assumes that the bitwise zero equivalent of any field is a 
sensible default value.

But this is not the case for LLVMCodeModel, or its internal equivalent, llvm::CodeModel::Model.  In both of those, the default 
for a JIT is CodeModel::JITDefault (or LLVMCodeModelJITDefault), which is not bitwise zero.

Hence this change introduces LLVMInitializeMCJITCompilerOptions(), which will initialize the user's options struct with
defaults. The user will use this in the same way that they would have previously used memset() or bzero(). MCJITCAPITest.cpp
illustrates the change, as does the comment in ExecutionEngine.h.

llvm-svn: 180893

As DejaGNU is deprecated, it seems pipe-jam issue doesn't exist any more.

llvm-svn: 180892

This avoids namespace collisions with llvm::LLVMTargetMachine.

llvm-svn: 180891

This goes with r178516, which instructed the analyzer not to inline the
constructors and destructors of C++ container classes. This goes a step
further and does the same thing for iterators, so that the analyzer won't
falsely decide we're trying to construct an iterator pointing to a
nonexistent element.

The heuristic for determining whether something is an iterator is the
presence of an 'iterator_category' member. This is controlled under the
same -analyzer-config option as container constructor/destructor inlining:
'c++-container-inlining'.

<rdar://problem/13770187>

llvm-svn: 180890

llvm-svn: 180889

to report proper errors when the size is not
correct.

<rdar://problem/13784456>

llvm-svn: 180888

<rdar://problem/13723772>

Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves.

A few things are introduced:
- lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread.
- Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification.
- Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them
- Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation.

llvm-svn: 180886

llvm-svn: 180885

PredicateInstruction function.

llvm-svn: 180884

The old jit always uses DW_EH_PE_absptr, but MCJIT can use other encodings.
This is in preparation for adding EH support to MCJIT, but not directly
related, so I am committing it first.

llvm-svn: 180883

llvm-svn: 180882

the things, and renames it to CBindingWrapping.h.  I also moved 
CBindingWrapping.h into Support/.

This new file just contains the macros for defining different wrap/unwrap 
methods.

The calls to those macros, as well as any custom wrap/unwrap definitions 
(like for array of Values for example), are put into corresponding C++ 
headers.

Doing this required some #include surgery, since some .cpp files relied 
on the fact that including Wrap.h implicitly caused the inclusion of a 
bunch of other things.

This also now means that the C++ headers will include their corresponding 
C API headers; for example Value.h must include llvm-c/Core.h.  I think 
this is harmless, since the C API headers contain just external function 
declarations and some C types, so I don't believe there should be any 
nasty dependency issues here.

llvm-svn: 180881

when doccumenting declrations in comments.
// rdar://13757500

llvm-svn: 180880

- TODO: Support extended register sets on FreeBSD.

Patch by Samuel Jacob.

llvm-svn: 180879

- Required for platform-independant handling of general purpose registers (i.e. for core dumps).

Thanks to Samuel Jacob for this patch.

llvm-svn: 180878

llvm-svn: 180877

- Also minor improvements to the comments and the expected results.

llvm-svn: 180876

SROA: Generate selects instead of shuffles when blending values because this is the cannonical form.
Shuffles are more difficult to lower and we usually don't touch them, while we do optimize selects more often.

llvm-svn: 180875

side because we need an inline asm diagnostics handler in place.  Unfortunately,
we emit a .s file because we need to build the SelectionDAG to hit the backend
issue.
rdar://13446483

llvm-svn: 180874

report a fatal error.  This allows us to continue processing the translation
unit.  Test case to come on the clang side because we need an inline asm
diagnostics handler in place.
rdar://13446483

llvm-svn: 180873

llvm-svn: 180872

Optimize CONCAT_VECTOR nodes that merge EXTRACT_SUBVECTOR values that extract from the same vector.

rdar://13402653
PR15866

llvm-svn: 180871

http://lab.llvm.org:8011/builders/lldb-x86_64-linux/builds/3810
http://lab.llvm.org:8011/builders/lldb-x86_64-debian-clang/builds/2754

llvm-svn: 180870

Updating the getting started guide for Visual Studio users. Specifically, pointing out that you have to pass additional parameters to llvm-lit and explicitly specify python on the command line.

llvm-svn: 180869

llvm-svn: 180868

Fix spurious trailing comma when printing some of the __c11_atomic_* builtins. Patch by Joe Sprowes!

llvm-svn: 180867

temporary to an lvalue before taking its address. This removes a weird special
case from the AST representation, and allows the constant expression evaluator
to deal with it without (broken) hacks.

llvm-svn: 180866