The tLDRr instruction with the last register operand set to the zero register
prints in assembly as if no register was specified, and the assembler encodes
it as a tLDRi instruction with a zero immediate.  With the integrated assembler,
that zero register gets emitted as "r0", so we get "ldr rx, [ry, r0]" which
is broken.  Emit the instruction as tLDRi with a zero immediate.  I don't
know if there's a good way to write a testcase for this.  Suggestions welcome.

Opportunities for follow-up work:
1) The asm printer should complain if a non-optional register operand is set
   to the zero register, instead of silently dropping it.
2) The integrated assembler should complain in the same situation, instead of
   silently emitting the operand as "r0".

llvm-svn: 154261

  performance, patched by Johannes Doerfert <johannes@jdoerfert.de>.

llvm-svn: 154260

llvm-svn: 154259

  patched by Johannes Doerfert <johannes@jdoerfert.de>.

llvm-svn: 154258

llvm-svn: 154255

llvm-svn: 154254

llvm-svn: 154252

Grouped unrolling means that we unroll a loop such that the different instances
of a certain statement are scheduled right after each other, but we do
not generate any vector code. The idea here is that we can schedule the
bb vectorizer right afterwards and use it heuristics to decide when
vectorization should be performed.

llvm-svn: 154251

nanoseconds in 32-bit expression would cause pthread_cond_timedwait
to time out immediately.  Add explicit casts to the TimeValue::TimeValue
ctor that takes a struct timeval and change the NanoSecsPerSec etc
constants defined in TimeValue to be uint64_t so any other calculations
involving these should be promoted to 64-bit even when lldb is built
for 32-bit.

<rdar://problem/11204073>, <rdar://problem/11179821>, <rdar://problem/11194705>.

llvm-svn: 154250

llvm-svn: 154249

  - The [class.protected] restriction is non-trivial for any instance
    member, even if the access lacks an object (for example, if it's
    a pointer-to-member constant).  In this case, it is equivalent to
    requiring the naming class to equal the context class.
  - The [class.protected] restriction applies to accesses to constructors
    and destructors.  A protected constructor or destructor can only be
    used to create or destroy a base subobject, as a direct result.
  - Several places were dropping or misapplying object information.

The standard could really be much clearer about what the object type is
supposed to be in some of these accesses.  Usually it's easy enough to
find a reasonable answer, but still, the standard makes a very confident
statement about accesses to instance members only being possible in
either pointer-to-member literals or member access expressions, which
just completely ignores concepts like constructor and destructor
calls, using declarations, unevaluated field references, etc.

llvm-svn: 154248

Cygwin-1.7 supports dw2. Some recent mingw distros support one, too.
I have confirmed test-suite/SingleSource/Benchmarks/Shootout-C++/except.cpp can pass on Cygwin.

llvm-svn: 154247

llvm-svn: 154246

string.

llvm-svn: 154243

a hello world executable from atoms.  There is still much to be flushed out.
Added one test case, test/darwin/hello-world.objtxt, which exercises the
darwin platform.

Added -platform option to lld-core tool to dynamically select platform.

llvm-svn: 154242

test/lit.cfg: Please pass %INCLUDE% to clang.exe on Win32. MS-compatible clang may refer to %INCLUDE%. It fixes r154188.

llvm-svn: 154240

Removed redundant isxdigit checks and added the ability to GetHexU8() so it can extract an 8 bit hex value if one is available. It will set EOF if "set_eof_on_fail" is true or if out of data. This allows a string decoder to grab a string without losing the last part of the packet with a packet like "414243,abc" (it can extract "ABC" and leave the file position set to the comma).

llvm-svn: 154239

by default.

This is a behaviour configurable in the MCAsmInfo. I've decided to turn
it on by default in (possibly optimistic) hopes that most assemblers are
reasonably sane. If this proves a problem, switching to default seems
reasonable.

I'm not sure if this is the opportune place to test, but it seemed good
to make sure it was tested somewhere.

llvm-svn: 154235

potential crash if the underlying type couldn't
be completed.

llvm-svn: 154234

However, the '-x' option has special handling and wasn't following this
paradigm.  Fix it to do so by claiming the arg as we parse the '-x' option.
rdar://11203340

llvm-svn: 154231

We sometimes need to be able to call functions (via Process::RunThreadPlan) from code run on the private state thread.  To do that we have to 
spin up a temporary "private state thread" that will respond to events from the lower level process plugins.  This check-in should work to do
that, but it is still buggy.  However, if you don't call functions on the private state thread, these changes make no difference.

This patch also moves the code in the AppleObjCRuntime step-through-trampoline handler that might call functions (in the case where the debug
server doesn't support the memory allocate/deallocate packet) out to a safe place to do that call.

llvm-svn: 154230

Windows users.

llvm-svn: 154229

documentation.

llvm-svn: 154228

llvm-svn: 154227

llvm-svn: 154226

In a few cases clang emitted a rather content-free diagnostic: 'parse error'.
This change replaces two actual cases (template parameter parsing and K&R
parameter declaration parsing) with more specific diagnostics and removes a
third dead case of this in the BalancedDelimiterTracker (the ctor already
checked the invariant necessary to ensure that the diag::parse_error was never
actually used).

llvm-svn: 154224

this file.

llvm-svn: 154222

--start argument.  Fixed that.

llvm-svn: 154221

llvm-svn: 154220

template parameters of pointer, pointer-to-member, or nullptr_t
type in C++11. Fixes PR9700 / <rdar://problem/11193097>.

llvm-svn: 154219

dictionary literals. This concludes // rdar://10803676

llvm-svn: 154218

llvm-svn: 154217

Rework ExprEngine::evalLoad and clients (e.g. VisitBinaryOperator) so that when we generate a new ExplodedNode
we use the same Expr* as the one being currently visited.  This is preparation for transitioning to having
ProgramPoints refer to CFGStmts.

This required a bit of trickery.  We wish to keep the old Expr* bindings in the Environment intact,
as plenty of logic relies on it and there is no reason to change it, but we sometimes want the Stmt* for
the ProgramPoint to be different than the Expr* being used for bindings.  This requires adding an extra
argument for some functions (e.g., evalLocation).  This looks a bit strange for some clients, but
it will look a lot cleaner when were start using CFGStmt* in the appropriate places.

As some fallout, the diagnostics arrows are a bit difference, since some of the node locations have changed.
I have audited these, and they look reasonable.

llvm-svn: 154214

llvm-svn: 154213

llvm-svn: 154212

llvm-svn: 154211

llvm-svn: 154210

After register masks were introdruced to represent the call clobbers, it
is no longer necessary to have duplicate instruction for iOS.

llvm-svn: 154209

the stress test by a LOT.

llvm-svn: 154208

llvm-svn: 154207