and offer fixits when there is a mismatch.

llvm-svn: 146326

commit-ish. Funny thing, they have a command designed for this. ;]

llvm-svn: 146325

revision and git commit data extracted. This will be used in the Clang
CMake build to avoid trying to re-detect the information.

llvm-svn: 146324

in CMake a bit more handy. Previously we would get such charming
versions as the following for revision NNNN and commit-ish XXXXX:
  3.1svnsvn-rNNNN
  3.1svngit-svn-rNNNN
  3.1svngit-svn-XXXXX

The mechanism selecting betwene the latter two was particularly odd, and
didn't work with all of the ways git-svn repos are set up apparently. It
also misses an important point -- both the revision *and* the git commit
might be relevant when working on a local branch some distance from
mainline. The new logic does several things:

1) It strips the redundant initial 'svn'.
2) It always looks for a git-svn revision number base, and when found
   includes it in the version.
3) If the git commit-ish for the current HEAD is not exactly that
   revision number, it is also included.

The resulting strings should roughly be:
  3.1svn-rNNNN
  3.1git-svn-rNNNN
  3.1git-svn-rNNNN-XXXXX

Suggestions on formatting etc always welcome. =] I've only looked at the
LLVM version string here, not Clang's (yet).

Note that the commit-ish reported is *not* terribly accurate. It updates
when 'cmake' is run, not when the binary is built. Still, it may be
better than nothing, especially if people have fairly long-lived git
repos and branches. This is not a new limitation, just didn't want
anyone to be surprised.

llvm-svn: 146323

Fixed bug 9905: Failure in code selection for llvm intrinsics sqrt/exp (fix for FSQRT, FSIN, FCOS, FPOWI, FPOW, FLOG, FLOG2, FLOG10, FEXP, FEXP2). Second attempt.

llvm-svn: 146322

llvm-svn: 146321

Move some print stmts to the test method, where they get printed only if the test is qualified to run
under the current test driver run configuration.

llvm-svn: 146320

Make CR spill and restore use a reserved register. These operations cannot use the register scavenger because the scavenger can only scavenge one register and frame-index elimination may have already grabbed it.

llvm-svn: 146318

expression parser would never try getting typed
variables from the target.

llvm-svn: 146317

llvm-svn: 146316

- Even if a frame isn't present, we always try
  to use FindGlobalVariable to find variables.
  Instead of using frame->TrackGlobalVariable()
  to promote the VariableSP into a ValueObject,
  we now simply use ValueObjectVariable.

- When requesting the value of a variable, we
  allow returning of the "live version" of the
  variable -- that is, the variable in the
  target instead of a pointer to its freeze
  dried version in LLDB -- even if there is no
  process present.

llvm-svn: 146315

The split point is picked such that the newly created water has the same
alignment as the function. This makes the island suitable for constant
pool entries with potentially higher alignment.

This also fixes an issue where the basic block was split one instruction
too late, causing nonconvergence of the algorithm.

<rdar://problem/10550705>

There is still an issue with correctly packing differently aligned
entries in the island.

llvm-svn: 146314

llvm-svn: 146313

a null pointer after getCursorDecl() is called. rdar://10298421.

llvm-svn: 146312

does. The _GLOBAL_OFFSET_TABLE_ is still magical in that we get a R_386_GOTPC,
but it doesn't change the immediate in the same way as when the expression
has no right hand side symbol.

llvm-svn: 146311

An assertion was firing when parsing types due to trying to complete parent
class decl contenxt types too often.

Also, relax where "dsymutil" binary can come from in the Makefile.rules.

llvm-svn: 146310

hard to ensure it doesn't get invalidated out from under us.  Instead look it up from the ThreadID
and StackID when asked for it.
<rdar://problem/10554409>

llvm-svn: 146309

and then continue using it. rdar://10359140.

llvm-svn: 146308

under ARC. Fixes <rdar://problem/10530209>.

llvm-svn: 146307

compilation of some translation units of SPEC's 445.gobmk by ~4%, and does not
seem to cause a measurable slowdown in other cases.

llvm-svn: 146306

we don't try to access beyond the buffer.

llvm-svn: 146305

// rdar://10095131

llvm-svn: 146304

llvm-svn: 146303

Since we're not rewriting IVs in other loops, there's not much reason
to consider their stride when generating formulae.
This should reduce the number of useless formulas considered by LSR.

llvm-svn: 146302

template instantiation), and that expression might produce a
temporary, invoke MaybeBindToTemporary. Otherwise, we forget to
destroy objects, release objects, etc. Fixes <rdar://problem/10531073>.

llvm-svn: 146301

llvm-svn: 146300

llvm-svn: 146299

-ffinite-math-only.
 - No test case yet, I don't know how to construct a situation where this
   matters.

llvm-svn: 146297

llvm-svn: 146296

creating appropriate setter/getter methods for
property definitions.

llvm-svn: 146295

FIXME: It should be more robust.
llvm-svn: 146294

llvm-svn: 146293

llvm-svn: 146292

llvm-svn: 146291

C++11 ICE rules.

llvm-svn: 146290

whether an expression is a (core) constant expression as a side-effect of
evaluation. This takes us from accepting far too few expressions as ICEs to
accepting slightly too many -- fixes for the remaining cases are coming next.

The diagnostics produced when an expression is found to be non-constant are
currently quite poor (with generic wording but reasonable source locations),
and will be improved in subsequent commits.

llvm-svn: 146289

llvm-svn: 146288

llvm-svn: 146287

llvm-svn: 146286

Backwards compatibility with 'gas'. #imm is the preferered and documented
syntax, but lots of existing code uses the '$' prefix, so we should
support it if we can.

llvm-svn: 146285