Teach each package configuration file to load the LLVMExports file for
its corresponding tree.  This will allow application CMake code to use
logical library and executable target names from LLVM as if they were in
our own build process (e.g. LLVMSupport).  CMake will have enough
information to propagate LLVM library link dependencies automatically
while configuring applications.

Contributed by Brad King.

llvm-svn: 201051

Record every logical target that we install with install(TARGETS) in a
global LLVM_EXPORTS property.  Then use the export(TARGETS) command to
provide a "LLVMExports.cmake" file that exports logical targets for
import into applications directly from our build tree.

The "LLVMExports.cmake" file is not meant for direct inclusion by
application code but should be included by "LLVMConfig.cmake" in a
future change.

Contributed by Brad King.

llvm-svn: 201050

Use the install(TARGETS) command EXPORT option for every library and
executable that we install with LLVM.  Then use the install(EXPORT)
command to provide a "LLVMExports.cmake" file that exports logical
targets for import into applications from our install tree.

The "LLVMExports.cmake" file is not meant for direct inclusion by
application code but should be included by "LLVMConfig.cmake" in a
future change.

Contributed by Brad King.

llvm-svn: 201049

Create separate package configuration files "LLVMConfig.cmake" for the
LLVM build and install trees so that each can have information specific
to its tree.  Configure each with the corresponding include, lib, and
cmake directories.  Include the "LLVM-Config" API modules directly from
the configured cmake modules directory.

In the install tree, compute the installation prefix relative to the
file location.  In the build tree, provide information specific to the
build tree for use by tools like Clang that can build externally against
the LLVM build tree.  Prefix such values in "LLVM_BUILD_" and comment
them as such.

Contributed by Brad King.

llvm-svn: 201048

Do not modify this value on the application's behalf and just ensure API
modules are always available next to the LLVMConfig module.  This is
already the case in the install tree so use file(COPY) to make it so in
the build tree.  Include the LLVM-Config API module from next to the
LLVMConfig location.

Contributed by Brad King.

llvm-svn: 201047

Use a LLVM_INSTALL_PACKAGE_DIR variable to hold the path and reference
it where necessary.

Contributed by Brad King.

llvm-svn: 201046

This enables a slightly odd feature of gas. The macro is defined when
the outermost macro is instantiated.

PR18599

llvm-svn: 201045

These methods normally call each other and it is really annoying if the
arguments are in different order. The more common rule was that the arguments
specific to call are first (GV, Encoding, Suffix) and the auxiliary objects
(Mang, TM) come after. This patch changes the exceptions.

llvm-svn: 201044

llvm-svn: 201043

don't turn it into a type ref.

rdar://15907618

llvm-svn: 201042

llvm-svn: 201041

llvm-svn: 201040

Remove some unnecessary code. The conditions it was checking had already been ruled out by the caller.

llvm-svn: 201039

Rather than simply saying "X is not a class or namespace", clarify what
X is by providing the aka type in the case where X is a type, or
pointing to the named declaration if there's an unambiguous one to refer
to. In the ambiguous case, the ambiguities are already enumerated
(though could be clarified by describing what kind of entities they are)

Included a few FIXMEs in tests where some further improvements could be
made.

llvm-svn: 201038

TargetInfo::getSuitableAlign() was introduced in r146762 and is defined
as alignof(std::max_align_t).

Introduce __ALIGNOF_MAX_ALIGN_T__ which exposes getSuitableAlign() so
that libc++ may take advantage of it.

llvm-svn: 201037

Properly apply the fix intended by SVN r201032.

llvm-svn: 201036

Fun fact: looking at the TableGen code (around TGParser.cpp:1166), the
only difference in handling is that adjacent regular string literals are
concatenated in the parser.

llvm-svn: 201035

Code fragments are just fancy string literals.

llvm-svn: 201034

They're called code fragments, but they are really multiline string
literals. Just spotted this usage in a patch by Aaron using "code
fragments" for holding documentation text. I remember someone bemoaning
the lack of multiline string literals in TableGen, so I'm explicitly
documenting that code fragments are multiline string literals.

Let it be known that any use case needing multiline string literals in
TableGen (such as descriptions of options, or whatnot) can use use
code fragments (instead of C-style string concatenation or exceedingly
long lines). E.g.

    class Bar<int n>;
    class Baz<int n>;
    class Doc<string desc> {
        string Desc = desc;
    }
    def Foo : Bar<1>, Baz<3>, Doc<[{
    This Foo is a Bar, and also a Baz. It can take 3 values:
        * Qux
        * Quux
        * Quuux
    }]>;

llvm-svn: 201033

llvm-svn: 201032

template parameters, don't look for parameters of outer templates. If a problem
is found in a default template argument, point the diagnostic at the partial
specialization (with a note pointing at the default argument) instead of
pointing it at the default argument and leaving it unclear which partial
specialization os problematic.

llvm-svn: 201031

In some cases it is possible to have a personality 0 unwinding opcodes in the
extab (such as when .handlerdata is used in the assembly).  Simply decode the 3
opcodes for that case.

llvm-svn: 201030

This makes the tests more readable by using the -arm-attributes decoding support
in llvm-readobj since that is now available.  Change the invocation commands to
be similar to other test and use a more precise triple (the tests only require
ARM EABI support).

llvm-svn: 201029

Before conditional store vectorization/unrolling we had only one
vectorized/unrolled basic block. After adding support for conditional store
vectorization this will not only be one block but multiple basic blocks. The
last block would have the back-edge. I updated the code to use a vector of basic
blocks instead of a single basic block and fixed the users to use the last entry
in this vector. But, I forgot to add the basic blocks to this vector!

Fixes PR18724.

llvm-svn: 201028

llvm-svn: 201027

llvm-svn: 201026

It is never null and it is not used in casts, so there is no reason to use a
pointer. This matches how we pass TM.

llvm-svn: 201025

llvm-svn: 201024

llvm-svn: 201023

llvm-svn: 201022

llvm-svn: 201021

unique them and permits the implementation of dynamic_cast (and
anything else which knows it's working with a complete class
type) to compare their addresses directly.

rdar://16005328

llvm-svn: 201020

Summary:
This avoids false positives from -Wmicrosoft when name lookup would
normally succeed in standard C++.  This triggered on a common CRTP
pattern in clang, where a derived class would have a private using decl
to pull in members of a dependent base:

class Verifier : InstVisitor<Verifier> {
private:
  using InstVisitor<Verifier>::visit;
  ...
  void anything() {
    visit(); // warned here
  }
};

Real access checks pass here because we're in the context of the
Verifier, but the -Wmicrosoft extension was just looking for the private
access specifier.

Reviewers: rsmith

CC: cfe-commits

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

llvm-svn: 201019

whether it's POD.

llvm-svn: 201018

LLVM only knows how to emit Z7-style line tables on -win32, so there's
no reason for clang to emit anything other than line info.

llvm-svn: 201017

llvm-svn: 201016

llvm-svn: 201015

as required per core issue 1552 and warned about with
-Wimplicit-exception-spec-mismatch.

llvm-svn: 201014

This was crashing compilation of DeclContext::buildLookupImpl<>.

llvm-svn: 201013

llvm-svn: 201012