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
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
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
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
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
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
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
Jim Ingham