* 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

to define a special member function as deleted so that it properly
establishes an object context for the accesses to the base subobject
members.

llvm-svn: 154343

--- log message follows this test ---
[tests] Fixup some tests to work in "CLANG_IS_PRODUCTION" mode.

llvm-svn: 154342

GOT if jump table uses 64-bit gp-relative relocation.

llvm-svn: 154341

in-register, such that we can use a single vector store rather then a 
series of scalar stores.

For func_4_8 the generated code

	vldr	d16, LCPI0_0
	vmov	d17, r0, r1
	vadd.i16	d16, d17, d16
	vmov.u16	r0, d16[3]
	strb	r0, [r2, #3]
	vmov.u16	r0, d16[2]
	strb	r0, [r2, #2]
	vmov.u16	r0, d16[1]
	strb	r0, [r2, #1]
	vmov.u16	r0, d16[0]
	strb	r0, [r2]
	bx	lr

becomes

	vldr	d16, LCPI0_0
	vmov	d17, r0, r1
	vadd.i16	d16, d17, d16
	vuzp.8	d16, d17
	vst1.32	{d16[0]}, [r2, :32]
	bx	lr

I'm not fond of how this combine pessimizes 2012-03-13-DAGCombineBug.ll,
but I couldn't think of a way to judiciously apply this combine.

This

	ldrh	r0, [r0, #4]
	strh	r0, [r1]

becomes

	vldr	d16, [r0]
	vmov.u16	r0, d16[2]
	vmov.32	d16[0], r0
	vuzp.16	d16, d17
	vst1.32	{d16[0]}, [r1, :32]

PR11158
rdar://10703339

llvm-svn: 154340

Work around a deadlocking issue where "SBDebugger::MemoryPressureDetected ()" is being called and is causing a deadlock. We now just try and get the lock when trying to trim down the unique modules so we don't deadlock debugger GUI programs until we can find the root cause.

llvm-svn: 154339

This patch restores TwoAddressInstructionPass's pre-r153892 behaviour when
rescheduling instructions in TryInstructionTransform. Hopefully this will fix
PR12493. To refix PR11861, lowering of INSERT_SUBREGS is deferred until after
the copy that unties the operands is emitted (this seems to be a more
appropriate fix for that issue anyway).

llvm-svn: 154338

Pointed out by: Sebastian Pop  <sebpop@gmail.com>

llvm-svn: 154337

llvm-svn: 154336

correct compile commands on, based on an idea by Jordan Rose.

llvm-svn: 154335

cc1 option remains though to invoke default property synthesis.
// rdar://11209719

llvm-svn: 154334

as the driver option.
// rdar://11209719

llvm-svn: 154331

We currently want to look whether PWD is available - if PWD is available it will
get us the non-resolved current path, while fs::current_path will resolve
symlinks. The long term fix is to not rely on that behavior any more.

llvm-svn: 154330

llvm-svn: 154329

llvm-svn: 154327

[ASan] remove dispatch.h header once again - it's not present on Leopard, and we don't want to break the build of compiler-rt there. See https://trac.macports.org/ticket/33362

llvm-svn: 154326

Specifically, using a an integer outside [0, 1] as a boolean constant seems to
be an easy mistake to make with things like "x == a || b" where the author
intended "x == a || x == b".

The bug caused by calling SkipUntil with three token kinds was also identified
by a VC diagnostic & reported by Francois Pichet as review feedback for my
commit r154163. I've included test cases to verify the error recovery that was
broken/poorly implemented due to this bug.

The other fix (lib/Sema/SemaExpr.cpp) seems like that code was never actually
reached in any of Clang's tests & is related to Objective C features I'm not
familiar with, so I've not been able to construct a test case for it. Perhaps
someone else can.

llvm-svn: 154325

A couple of cases where we were accidentally creating constant conditions by
something like "x == a || b" instead of "x == a || x == b". In one case a
conditional & then unreachable was used - I transformed this into a direct
assert instead.

llvm-svn: 154324

llvm-svn: 154322

for hooking in code flow visualisation applications.  

llvm-svn: 154321

original patch to add itineraries, to X86InstrArithmetc.td.  

llvm-svn: 154320

less accurate method.

llvm-svn: 154319