This lets us run the unittest from the command line without setting
LD_LIBRARY_PATH.

llvm-svn: 202509

This is related to:
http://llvm.org/bugs/show_bug.cgi?id=16170

This test ran successfully 40 out of 40 times on Ubuntu 12.04 LTS
x86_64.

llvm-svn: 202508

Similar to my previous check-in related to:
http://llvm.org/bugs/show_bug.cgi?id=15037

10 out of 10 runs of this failed.  Mark it XFAIL.

llvm-svn: 202507

Related to this bug:
http://llvm.org/bugs/show_bug.cgi?id=15037

Previously this was marked as skipped. I tried running it 10 times in
a row and it failed every time. Switched it to XFAIL.

llvm-svn: 202506

llvm-svn: 202505

llvm-svn: 202504

llvm-svn: 202503

llvm-svn: 202502

Adding a test case to ensure that type attributes applied to the decl-specifier are applied across all declarations in a group.

llvm-svn: 202501

llvm-svn: 202500

This centralizes the Makefile handling of -install_name and -rpath. It also
moves the cmake build to using @rpath. The reason being that libclang needs it,
and it works for everything else.

A followup patch will move clang to using this and then there will be a single
point to edit to support other systems.

llvm-svn: 202499

llvm-svn: 202498

A lot of this is writing down common knowledge and things often
communicated on mailing lists and in discussions. It could live in the
Programmer's Manual alternatively, but that felt slightly less
well-fitting.

It also includes (and was motivated by) the section on the relevant
language standards for LLVM and the specific features that will be
enabled with the switch to C++11.

With this, all of the documentation for the C++11 switch is, I think, in
place. I plan to flip the switch RSN. =]

llvm-svn: 202497

X86Operand is extracted into individual header, because it allows to create an
arbitrary memory operand and append it to MCInst. It'll be reused in X86 inline
assembly instrumentation.

Patch by Yuri Gorshenin.

llvm-svn: 202496

standards.

It claims the document intentionally doesn't give fixed standards for
brace placement or spacing, and then the document goes on to do
precisely that in several places. Instead, try to highlight that even
these rules are simply *guidance* which may be trumped by some other
circumstance or the local conventions of code.

I'm not trying to change the thrust of this part of the document, and if
folks think this does so, I'm happy to re-wordsmith it. I just don't
want it to be so self-contradicting.

llvm-svn: 202495

for the style templates we're using.

llvm-svn: 202494

hopefully easier to get the formatting right for ReST.

llvm-svn: 202493

llvm-svn: 202492

PR18999.

llvm-svn: 202491

llvm-svn: 202490

llvm-svn: 202489

FreeBSD 10.0 and newer have a modern Clang toolchain that should work
well.

llvm-svn: 202488

[sanitizer] speedup deadlock detector for the case when we destroy a mutex that has never been locked

llvm-svn: 202487

a more modern host C++ toolchain for Linux distros where folks sometimes
don't have a good option to get one as part of their system.

This is a first cut, so feedback, testing, and suggestions are very,
very welcom. This is one of the last real documentation changes that was
specifically requested prior to switching LLVM and Clang to build in
C++11 mode by default.

llvm-svn: 202486

Introduce DDetector interface between the tool and the DD itself.
It will help to experiment with other DD implementation,
as well as reuse DD in other tools.

llvm-svn: 202485

llvm-svn: 202484

llvm-svn: 202483

llvm-svn: 202482

They are not needed any more.

llvm-svn: 202481

llvm-svn: 202480

  * Align targets of indirect jumps to instruction bundle boundaries (in MI layer).
  * Add masking instructions before indirect jumps (in MC layer).

Differential Revision: http://llvm-reviews.chandlerc.com/D2847

llvm-svn: 202479

Port the OpenMP runtime to FreeBSD along with associated build system changes.

Also begin to generalize affinity capabilities so they aren't tied explicitly
to Windows and Linux.

The port builds with stock clang and gmake and has no additional runtime
dependencies.

All but a handful of the validation suite tests are now passing on FreeBSD 10
x86_64.

llvm-svn: 202478

llvm-svn: 202477

llvm-svn: 202476

A 'remark' is information that is not an error or a warning, but rather some
additional information provided to the user. In contrast to a 'note' a 'remark'
is an independent diagnostic, whereas a 'note' always depends on another
diagnostic.

A typical use case for remark nodes is information provided to the user, e.g.
information provided by the vectorizer about loops that have been vectorized.

This patch provides the initial implementation of 'remarks'. It includes the
actual definiton of the remark nodes, their printing as well as basic parameter
handling. We are reusing the existing diagnostic parameters which means a remark
can be enabled with normal '-Wdiagnostic-name' flags and can be upgraded to
an error using '-Werror=diagnostic-name'. '-Werror' alone does not upgrade
remarks.

This patch is by intention minimal in terms of parameter handling. More
experience and more discussions will most likely lead to further enhancements
in the parameter handling.

llvm-svn: 202475

A 'remark' is information that is not an error or a warning, but rather some
additional information provided to the user. In contrast to a 'note' a 'remark'
is an independent diagnostic, whereas a 'note' always depends on another
diagnostic.

A typical use case for remark nodes is information provided to the user, e.g.
information provided by the vectorizer about loops that have been vectorized.

llvm-svn: 202474

llvm-svn: 202473

llvm-svn: 202472

this is inherently unsafe.

Instead get the diagnostic info into a SourceManager-independent form.

llvm-svn: 202471

llvm-svn: 202470