From now on we allow the clients to override signal handlers set by ASan, but print a warning in such a case.

Remove the tests for signal() and sigaction(), because they made little sense even without this change.

llvm-svn: 154390

llvm-svn: 154389

rational number, eg as 2.5 rather than 5, 2.  OK'd by Peter Collingbourne.

llvm-svn: 154388

rational number, eg as 2.5 rather than 5, 2.  OK'd by Peter Collingbourne.

llvm-svn: 154387

Take this opportunity to generalize the indirectbr bailout logic for
loop transformations. CFG transformations will never get indirectbr
right, and there's no point trying.

llvm-svn: 154386

llvm-svn: 154385

llvm-svn: 154384

llvm-svn: 154383

Recent refactoring introduced a bug. Fix: added buildRegUnitSets.

llvm-svn: 154382

 * Alternative tokens (such as 'compl') are treated as identifiers in
   attribute names.
 * An attribute-list can start with a comma.
 * An ellipsis may not be used with either of our currently-supported
   C++11 attributes.

llvm-svn: 154381

	QListThreadsInStopReply
	
This GDB remote query command can enable added a "threads" key/value pair to all stop reply packets so that we always get a list of all threads in each stop reply packet. It increases performance if enabled (the reply to the "QListThreadsInStopReply" is "OK") by saving us from sending to command/reply pairs (the "qfThreadInfo" and "qsThreadInfo" packets), and also helps us keep the current process state up to date. 

llvm-svn: 154380

llvm-svn: 154379

llvm-svn: 154378

Jakob's review.

llvm-svn: 154377

A general stability fix where we _always_ get the thread list immediately after we get the stop packets. We had some racy conditions where thread 1 might be sending a packet and thread 2 tries to send a packet to get the thread list and it fails and ends up with an empty list. Packets use a sequence mutex to be able to ensure when you send a packet, you get the resonse. This sequence mutex is take when the process is running, and as we exit the running state and notify our process with the stop packet, we now always get the thread ID list before we do anything and before we can run into race conditions. 

The next step is to have our stop reply packets send the thread list in the actual stop reply packet to avoid a 2 packet overhead of sending the qfThreadInfo + response and qfThreadInfo + response.

llvm-svn: 154376

llvm-svn: 154375

This is a new algorithm that finds sets of register units that can be
used to model registers pressure. This handles arbitrary, overlapping
register classes. Each register class is associated with a (small)
list of pressure sets. These are the dimensions of pressure affected
by the register class's liveness.

llvm-svn: 154374

This is a new algorithm that associates registers with weighted
register units to accuretely model their effect on register
pressure. This handles registers with multiple overlapping
subregisters. It is possible, but almost inconceivable that the
algorithm fails to find an exact solution for a target description. If
an exact solution cannot be found, an inexact, but reasonable solution
will be chosen.

llvm-svn: 154373

llvm-svn: 154372

llvm-svn: 154371

legalizer always use the DAG entry node. This is wrong when the libcall is
emitted as a tail call since it effectively folds the return node. If
the return node's input chain is not the entry (i.e. call, load, or store)
use that as the tail call input chain.

PR12419
rdar://9770785
rdar://11195178

llvm-svn: 154370

 * In C++11, '[[' is ill-formed unless it starts an attribute-specifier. Reject
   array sizes and array indexes which begin with a lambda-expression. Recover by
   parsing the lambda as a lambda.
 * In Objective-C++11, either '[' could be the start of a message-send.
   Fully disambiguate this case: it turns out that the grammars of message-sends,
   lambdas and attributes do not actually overlap. Accept any occurrence of '[['
   where either '[' starts a message send, but reject a lambda in an array index
   just like in C++11 mode.

Implement a couple of changes to the attribute wording which occurred after our
attributes implementation landed:
 * In a function-declaration, the attributes go after the exception specification,
   not after the right paren.
 * A reference type can have attributes applied.
 * An 'identifier' in an attribute can also be a keyword. Support for alternative
   tokens (iso646 keywords) in attributes to follow.

And some bug fixes:
 * Parse attributes after declarator-ids, even if they are not simple identifiers.
 * Do not accept attributes after a parenthesized declarator.
 * Accept attributes after an array size in a new-type-id.
 * Partially disamiguate 'delete' followed by a lambda. More work is required
   here for the case where the lambda-introducer is '[]'.

llvm-svn: 154369

1) Start the PrivateStateThread stopped, and then in
StartPrivateStateThread, make the private state thread and then
resume it before we say the thread is created.  That way we know it is
listening for events by the time we get out of
StartPrivateStateThread.

2) Backstop running a thread plan when calling Process::RunThreadPlan
on the private state thread with a ThreadPlanBase so that running the
plan doesn't pass its stop events to whatever plans happen to be above
us on the thread plan stack.

llvm-svn: 154368

Clear the "m_actual_stop_info_sp" in the thread during Destroy.  It might be a StopInfoThreadPlan, and that would hold onto members that need to be destroyed while the Full thread is still around.

llvm-svn: 154366

The current ProcessGDBRemote function that updates the threads could end up with an empty list if any other thread had the sequence mutex. We now don't clear the thread list when we can't access it, and we also have changed how lldb_private::Process handles the return code from the:

virtual bool
Process::UpdateThreadList (lldb_private::ThreadList &old_thread_list, 
                       	   lldb_private::ThreadList &new_thread_list) = 0;

A bool is now returned to indicate if the list was actually updated or not and the lldb_private::Process class will only update the stop ID of the validity of the thread list if "true" is returned.

The ProcessGDBRemote also got an extra assertion that will hopefully assert when running debug builds so we can find the source of this issue.

llvm-svn: 154365

not fit in a i64.

llvm-svn: 154364

llvm-svn: 154363

Generalized logic of r154141.

llvm-svn: 154362

Fixing a problem where some uninitialized cases of vectors could cause diagnostic output from the synthetic children providers - this time the fix should work

llvm-svn: 154361

implicit casts which is needed to produce good c++
code. // rdar://11202764

llvm-svn: 154360

llvm-svn: 154359

requires the -plugin to come before any -plugin-opt options, we were passing
them the other way around. With this one can run (for example):

clang -o foo foo.c -O4 -Wl,-plugin-opt=generate-api-file

llvm-svn: 154357

Revert the 'EnableInitializing' flag. There is debate on whether we should run that pass by default in LTO.

llvm-svn: 154356

Added a packet history object to the GDBRemoteCommunication class that is always remembering the last 512 packets that were sent/received. These packets get dumped if logging gets enabled, or when the new expr lldb::DumpProcessGDBRemotePacketHistory (void *process, const char *log_file_path) global function is called.

llvm-svn: 154354

llvm-svn: 154353

Fixed an issue that could occur when looking up functions inside of a namespace where if the NamespaceDecl hadn't been parsed yet, we would say a function wasn't in a namespace.

Also improved the logging that happens with "log enable dwarf lookups" is enabled to show when we find matches.

llvm-svn: 154352

Rework how master plans declare themselves.  Also make "PlanIsBasePlan" not rely only on this being the bottom plan in the stack, but allow the plan to declare itself as such.

llvm-svn: 154351

Apply the scope restrictions after parsing the command line options. There may be some which are used in that function.

llvm-svn: 154348

to c-index-test.

llvm-svn: 154347

base-class subojects.

Incidentally, thinking about virtual bases makes it clear to me that
we're not appropriately computing the access to the virtual base's
member because we're not computing the best possible access to the
virtual base at all;  in fact, we're basically assuming it's public.
I'll file a separate PR about that.

llvm-svn: 154346