This reverts commit r260194.

It caused PR26549. There's probably a better way to do this also.

llvm-svn: 260241

As mentioned in http://reviews.llvm.org/D16828 , the related masked load transform
will need this logic, so I'm moving it out to make that patch smaller.

llvm-svn: 260240

Summary: This also fixes an infinite recursion between lldb_private::operator>> () and Scalar::operator>>= ().

Reviewers: sagar, tberghammer, labath

Subscribers: lldb-commits

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

Patch by Marianne Mailhot-Sarrasin

llvm-svn: 260239

Use the VFTable components to determine whether or not we should emit
RTTI data instead of duplicating the VFTableBuilder's logic.

llvm-svn: 260238

Summary:
This fixes the tests under std/atomics for 32-bit MIPS CPUs where the
8-byte atomic operations call into the libatomic library.

Reviewers: dsanders, mclow.lists, EricWF, jroelofs, joerg

Subscribers: cfe-commits

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

llvm-svn: 260235

Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.

For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when lsan tests fail since their
name no longer implies that they are trying to test the default target.

Reviewers: samsonov

Subscribers: tberghammer, danalbert, llvm-commits, srhines

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

llvm-svn: 260232

Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.

For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when msan tests fail since their
name no longer implies that they are trying to test the default target.

Reviewers: samsonov

Subscribers: tberghammer, danalbert, llvm-commits, srhines

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

llvm-svn: 260231

Summary:
Previously, the tests only ran for the 64-bit equivalent of the default target
(see -m64).
Given the supported architecture list only contains 64-bit targets, this happens
to work out the same as the supported targets in most cases but may matter for
X86_64/X86_64h on Darwin.

For other targets, the practical effect is that the test names contain the
architecture. This resolves some confusion when msan tests fail since their
name no longer implies that they are trying to test the default target.

Reviewers: samsonov

Subscribers: tberghammer, danalbert, srhines, llvm-commits

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

llvm-svn: 260230

llvm-svn: 260229

llvm-svn: 260228

Summary:
This fixes duplicate test names in the test results, so:
  PASS: SanitizerCommon-asan :: fopen_nullptr.c (304 of 431)
  PASS: SanitizerCommon-asan :: fopen_nullptr.c (305 of 431)
is now:
  PASS: SanitizerCommon-asan-i386-Linux :: fopen_nullptr.c (282 of 431)             
  PASS: SanitizerCommon-asan-x86_64-Linux :: fopen_nullptr.c (316 of 431)

Reviewers: samsonov

Subscribers: llvm-commits

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

llvm-svn: 260227

llvm-svn: 260226

llvm-svn: 260225

This is the function equivalent of a copy relocation.

Since functions are expected to change sizes, we cannot use copy
relocations. In situations where one would be needed, what is done
instead is:
* Create a plt entry
* Output an undefined symbol whose addr is the plt entry.

The dynamic linker makes sure any shared library uses the plt entry as
the function address.

llvm-svn: 260224

Reviewers: alexfh

Subscribers: cfe-commits

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

llvm-svn: 260223

Registering the gnuNullExpr AST matcher as a dynamic matcher so that it is available from clang-query.

llvm-svn: 260222

llvm-svn: 260221

llvm-svn: 260220

llvm-svn: 260219

llvm-svn: 260218

llvm-svn: 260217

llvm-svn: 260216

directive.

llvm-svn: 260215

llvm-svn: 260214

llvm-svn: 260213

llvm-svn: 260212

Clang did not expanded macros in the very first token of the pragmas
during preprocessed output

llvm-svn: 260211

On AVX2 target we are poorly legalizing SIGN_EXTEND ops for which the input's legalized type doesn't have the same number of elements as the destination, resulting in an ANY_EXTEND followed by a SIGN_EXTEND_INREG.

This patch uses the existing SIGN_EXTEND -> SIGN_EXTEND_VECTOR_INREG combine to extend the input to the size of the result and using SIGN_EXTEND_VECTOR_INREG instead.

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

llvm-svn: 260210

llvm-svn: 260209

llvm-svn: 260208

llvm-svn: 260207

Introduce the feature 'demangler' in check-lld. Mark lld/test/old-elf/X86_64/demangle.test as REQUIRES:demangler.

llvm-svn: 260206

llvm-svn: 260205

(libgomp has bool as well)

This was causing a test failure in omp_test_if.c when building with GCC in
Debug mode. I have verified that GCC versions 4.9.2 and 5.3.0 now work and
compile-tested this change with clang 3.7.1 and Intel Compiler 16.0.

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

llvm-svn: 260204

This is in response to silvas' post-commit suggestion.

llvm-svn: 260203

llvm-svn: 260202

This cache file can be used to generate a 3-stage clang build. You can configure using the following CMake command:

cmake -C <path to clang>/cmake/caches/3-stage.cmake -G Ninja <path to llvm>

You can then run "ninja stage3-clang" to build stage1, stage2 and stage3 clangs.

This is useful for finding non-determinism the compiler by verifying that stage2 and stage3 are identical.

llvm-svn: 260201

llvm-svn: 260200

This is because PyThreadState_Get() assumes a non-NULL thread state and crashes otherwise; but PyThreadState_GET is just a shortcut (in non-Python-debugging builds) for the global variable that holds the thread state

The behavior of CTRL+C is slightly more erratic than one would like. CTRL+C in the middle of execution of Python code will cause that execution to be interrupted (e.g. time.sleep(1000)), but a CTRL+C at the prompt will just cause a KeyboardInterrupt and not exit the interpreter - worse, it will only trigger the exception once one presses ENTER.

None of this is optimal, of course, but I don't have a lot of time to appease the Python deities with the proper spells right now, and fixing the crasher is already a good thing in and of itself

llvm-svn: 260199

llvm-svn: 260198