Summary:
Replace unrecognized namespace ending comments. This will help in particular when a namespace ending comment is mistyped or doesn't fit the regexp for other reason, e.g.:

  namespace a {
  namespace b {
  namespace {
  } // anoynmous namespace
  } // b
  } // namesapce a

Reviewers: djasper

Reviewed By: djasper

Subscribers: curdeius, cfe-commits

Differential Revision: http://reviews.llvm.org/D8078

llvm-svn: 231369

llvm-svn: 231368

Long story short: stop-the-world briefly resets SIGSEGV handler to SIG_DFL.
This breaks programs that handle and continue after SIGSEGV (namely JVM).
See the test and comments for details.

This is reincarnation of reverted r229678 (http://reviews.llvm.org/D7722).
Changed:
- execute TracerThreadDieCallback only on tracer thread
- reset global data in TracerThreadSignalHandler/TracerThreadDieCallback
- handle EINTR from waitpid

Add 3 new test:
- SIGSEGV during leak checking
- StopTheWorld operation during signal storm from an external process
- StopTheWorld operation when the program generates and handles SIGSEGVs

http://reviews.llvm.org/D8032

llvm-svn: 231367

Teach lowering to correctly handle invoke statepoint and gc results tied to them. Note that we still can not lower gc.relocates for invoke statepoints.
Also it extracts getCopyFromRegs helper function in SelectionDAGBuilder as we need to be able to customize type of the register exported from basic block during lowering of the gc.result.

llvm-svn: 231366

http://reviews.llvm.org/D8071

Patch by Alexey Sokolov!

llvm-svn: 231365

http://reviews.llvm.org/D7994

Patch by Richard Thomson!

llvm-svn: 231364

Added a REQUIRES for the Mips target.
Also, switched to using plain CHECKs, at the suggestion of Eric Christopher.

llvm-svn: 231363

llvm-svn: 231362

Reviewed at http://reviews.llvm.org/D8049

llvm-svn: 231361

Build time (user time) for building llvm+clang+lldb in release mode:
 - default allocator: 9086 seconds
 - with PBQP: 9126 seconds
 - with PBQP + local bit matrix cache: 9097 seconds

llvm-svn: 231360

isNormalFp and isFiniteNonZeroFp should not assume vector operands can not be constant expressions.

Patch by Pawel Jurek <pawel.jurek@intel.com>
Differential Revision: http://reviews.llvm.org/D8053

llvm-svn: 231359

Revert "[TableGen] Implement at least some support for multiple explicit results in an instruction pattern. No functional change to existing patterns."

This is failing on several build bots.

llvm-svn: 231358

[TableGen] Implement at least some support for multiple explicit results in an instruction pattern. No functional change to existing patterns.

This should help with the AVX512 masked gather changes Elena is working on. This patch is derived from some of the changes Elena made to tablegen, but modified by me to support arbitrary number of results.

llvm-svn: 231357

[TableGen] Add support constraining a vector type in a pattern to have a specific element type and for constraining a vector type to have the same number of elements as another vector type. This is useful for AVX512 mask operations so we relate the mask type to the type of the other arguments.

llvm-svn: 231356

llvm-svn: 231355

llvm-svn: 231354

Pointed out by Paul Robinson.

llvm-svn: 231353

These came from my own experience and may not apply equally to all use cases.  Any alternate perspective anyone has should be used to refine these.  

As always, grammar and spelling adjustments are more than welcome.  Please just directly commit a fix if you see something problematic.

llvm-svn: 231352

This reverts commit r231350.

It turns out MSVC doesn't generate implicit move constructors and also doesn't accept to default them...
See for example http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc/builds/2786

llvm-svn: 231351

llvm-svn: 231350

llvm-svn: 231349

See PR22799.

llvm-svn: 231348

already been added and the inconsistency made choosing names and
changing code more annoying. Plus, wow are they better for this code!

llvm-svn: 231347

llvm-svn: 231346

This hook is called from one of the hottest loops in LLD and does nothing.

llvm-svn: 231345

 - GCC doesn't support #pragma mark, only Apple GCC and clang. Wrap the pragma mark's in #if 0 to make gcc ignore them but xcode still see them.
 - Wrap a bunch of "#pragma clang" lines in #ifdef __clang__.
 - Pacify gcc's -Wparenthesis in a case where it's quite reasonable.

llvm-svn: 231344

llvm-svn: 231343

operator in addition to the vendor-extension DW_OP_GNU_push_tls_address.
clang on PS4 and Darwin will be emitting the standard opcode 
as of r231286 via http://reviews.llvm.org/D8018

Behavior of this standard  opcode is the same as 
DW_OP_GNU_push_tls_address.

<rdar://problem/20043195>

llvm-svn: 231342

result reasonable.

This code predated clang-format and so there was a reasonable amount of
crufty formatting that had accumulated. This should ensure that neither
myself nor others end up with formatting-only changes sneaking into
other fixes.

llvm-svn: 231341

gone, update this code to reflect that.

llvm-svn: 231340

Patch by Michael Edwards!

llvm-svn: 231339

llvm-svn: 231338

llvm-svn: 231337

llvm-svn: 231336

It is miscompiled on msc18.

llvm-svn: 231335

llvm-svn: 231334

llvm-svn: 231333

just arbitrarily interleaving unrelated control flows once they get
moved "out-of-line" (both outside of natural CFG ordering and with
diamonds that cannot be fully laid out by chaining fallthrough edges).

This easy solution doesn't work in practice, and it isn't just a small
bug. It looks like a very different strategy will be required. I'm
working on that now, and it'll again go behind some flag so that
everyone can experiment and make sure it is working well for them.

llvm-svn: 231332

llvm-svn: 231331

llvm-svn: 231330