editing of the current interval.

These methods may cause coalescing, there are corresponding set*Unchecked
methods for editing without coalescing. The non-coalescing methods are useful
for applying monotonic transforms to all keys or values in a map without
accidentally coalescing transformed and untransformed intervals.

llvm-svn: 120829

llvm-svn: 120828

llvm-svn: 120827

llvm-svn: 120826

inferior to be launched without setting up terminal stdin/stdout for it
(leaving the lldb command line accessible while the program is executing).
Also add a user settings variable, 'target.process.disable-stdio' to allow
the user to set this globally rather than having to use the command option
each time the process is launched.

llvm-svn: 120825

llvm-svn: 120824

llvm-svn: 120822

llvm-svn: 120821

llvm-svn: 120820

llvm-svn: 120819

llvm-svn: 120818

llvm-svn: 120817

llvm-svn: 120816

For some reason these were not included in the list of Neon intrinsics in
ARM's documentation, so they didn't make it into Clang either.

llvm-svn: 120815

Fixed an issue that would cause an assertion to fire when an inlined function was found during a regex function find call.

llvm-svn: 120814

llvm-svn: 120813

llvm-svn: 120812

llvm-svn: 120810

instead of just converting the record name to lowercase.

llvm-svn: 120809

declarations.

The motivation for this patch is that linkage/visibility computations
are linear in the number of redeclarations of an entity, and we've run
into a case where a single translation unit has > 6500 redeclarations
of the same (unused!) external variable. Since each redeclaration
involves a linkage check, the resulting quadratic behavior makes Clang
slow to a crawl. With this change, a simple test with 512
redeclarations of a variable syntax-checks ~20x faster than
before.

That said, I hate this change, and will probably end up reverting it
in a few hours. Reasons to hate it:
  - It makes NamedDecl larger, since we don't have enough free bits in
  Decl to squeeze in the extra information about caching.
  - There are way too many places where we need to invalidate this
  cache, because the visibility of a declaration can change due to
  redeclarations (!). Despite self-hosting and passing the testsuite,
  I have no confidence that I've found all of places where this cache
  needs to be invalidated.

llvm-svn: 120808

This is currently the same as a lowercase version of the record name, but
it will allow us to have multiple records with the same name, which is
needed for intrinsics (e.g., vmul and vmull) that are implemented
differently depending on the type.

llvm-svn: 120807

to distinguish vsri/vsli.

llvm-svn: 120806

llvm-svn: 120804

llvm-svn: 120803

llvm-svn: 120802

Try to fix building on the wayback machine.

llvm-svn: 120801

llvm-svn: 120800

llvm-svn: 120799

llvm-svn: 120796

a node in the trimmed graph might not always
correctly map back to the original error node.
This could cause a crash in some cases when
flagging memory leaks.

llvm-svn: 120795

when generating DOT output for an ExplodedGraph.

llvm-svn: 120794

an error saying the resume timed out. Previously the thread that was trying
to resume the process would eventually call ProcessGDBRemote::DoResume() which
would broadcast an event over to the async GDB remote thread which would sent the
continue packet to the remote gdb server. Right after this was sent, it would
set a predicate boolean value (protected by a mutex and condition) and then the
thread that issued the ProcessGDBRemote::DoResume() would then wait for that
condition variable to be set. If the async gdb thread was too quick though, the
predicate boolean value could have been set to true and back to false by the
time the thread that issued the ProcessGDBRemote::DoResume() checks the boolean
value. So we can't use the predicate value as a handshake. I have changed the code
over to using a Event by having the GDB remote communication object post an
event: 

	GDBRemoteCommunication::eBroadcastBitRunPacketSent

This allows reliable handshaking between the two threads and avoids the erroneous
ProcessGDBRemote::DoResume() errors.

Added a host backtrace service to allow in process backtraces when trying to track
down tricky issues. I need to see if LLVM has any backtracing abilities abstracted
in it already, and if so, use that, but I needed something ASAP for the current issue
I was working on. The static function is:

void
Host::Backtrace (Stream &strm, uint32_t max_frames);

And it will backtrace at most "max_frames" frames for the current thread and can be
used with any of the Stream subclasses for logging.

llvm-svn: 120793

llvm-svn: 120792

llvm-svn: 120791

llvm-svn: 120790

llvm-svn: 120788

difference is much smaller (about 0.3s) but significant.

llvm-svn: 120787

llvm-svn: 120786

llvm-svn: 120785

a file exists when it shouldn't.

llvm-svn: 120784