This is the first of a series of patches to handle type uniqueing of the
type array for a subroutine type.

This commit makes sure unspecified_parameter is a DIType to enable converting
the type array for a subroutine type to an array of DITypes.

This commit should have no functionality change. With this commit, we may
change unspecified type to be a DITrivialType instead of a DIType.

llvm-svn: 214111

The new flag, WantFunctionLikeCasts, covers a subset of the keywords
covered by WantTypeSpecifiers that can be used in casts that look like
function calls, e.g. "return long(5);", while excluding the keywords
like "enum" and "const" that would be included when WantTypeSpecifiers
is true but cannot be used in something that looks like a function call.

llvm-svn: 214109

llvm-svn: 214108

The gcov compatible code is moved to its own file and
llvm-cov is updated to be a wrapper that always calls
the gcov main function.

llvm-svn: 214107

All the others use bool, so these should too.

llvm-svn: 214106

inspection in the proccess, and shuffle the logging in the DAG combiner
around a bit.

With this it is much easier to follow what the legalizer is doing. It
should even accurately present most of the strange legalization
operations where a single node is replaced by multiple nodes, etc. There
is still some information lost (we log SDNodes not SDValues so we don't
log which result is used for which thing), but I think this is much
closer to a usable system. Notably, this will make it *much* more
apparant when legalization is actually happening inside the combiner, or
when there is a cycle caused by interactions of the legalizer and the
combiner.

The "bug" I fixed here I'm not sure is remotely possible to trigger. We
were only adding one of the nodes in a replacement to the updated set
rather than all of the nodes in the replacement. Realistically, the
worst result of this are nodes not getting back onto the worklist in the
DAG combiner. I doubt it is possible to trigger this today, and
I certainly don't have any ideas about how, but this at least brings the
code into alignment with the principled operation of the routine.

llvm-svn: 214105

The default guess uses i32. This needs an address space argument
to really do the right thing in all cases.

llvm-svn: 214104

llvm-svn: 214103

llvm-svn: 214102

llvm-svn: 214101

llvm-svn: 214100

Part of <rdar://problem/17688758>

llvm-svn: 214099

Part of <rdar://problem/17688758>

llvm-svn: 214098

There is no functional change here.

The idea is to have a similar order and categories of functions that we have
in avxintrin.h.

llvm-svn: 214097

llvm-svn: 214096

llvm-svn: 214095

This patch creates a simple ProcessWindows process plugin.
The only thing it knows how to do currently is create processes.

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

llvm-svn: 214094

Assuming that the user's home directory is at ~ is incorrect on
Windows.  This patch delegates the request to LLVM's support
library, which already provides a cross-platform implementation
of this function.

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

llvm-svn: 214093

i386, i486, i486sx, and i686 are all indistinguishable as far as
PE/COFF files are concerned.  This patch adds support for all of
these architectures to PlatformWindows.

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

llvm-svn: 214092

llvm-svn: 214091

not auto synthesized in current implementation.
rdar://17774815

llvm-svn: 214090

til::SExpr.  This is a large patch, with many small changes to pretty printing
and expression lowering to make the new SExpr representation equivalent in
functionality to the old.

llvm-svn: 214089

Fix PR#20471. Add a cast in __align_it to ensure that the bit twiddling is done at the correct size. A better solution, IMHO, would be to declare vector<bool>::__bits_per_word as 'size_type', rather than 'unsigned', but that's a possible ABI change.

llvm-svn: 214088

llvm-svn: 214087

Added coverage for:
* More than one "off region" in the same file
* An "off region" falling off the end of an included file

llvm-svn: 214086

The exe-got.test test case is target independent.

llvm-svn: 214085

Initial patch and tests by Kaushik Sridharan, thank you!

llvm-svn: 214084

llvm-svn: 214082

Instructions: KAND{BWDQ}, KANDN{BWDQ}, KOR{BWDQ}, KXOR{BWDQ}, KXNOR{BWDQ}

Reviewed by Elena Demikhovsky <elena.demikhovsky@intel.com>

llvm-svn: 214081

use is deprecated in favour of llvm_map_components_to_libnames()

Although message(DEPRECATION "msg") would probably be a better fit this
does nothing if CMAKE_ERROR_DEPRECATED and CMAKE_WARNING_DEPRECATED are
both off, which is the default.

llvm-svn: 214078

libraries. With many contributions from Brad King.

llvm-svn: 214077

llvm-svn: 214076

Before:
  static_assert(is_convertible < A &&, B > ::value, "AAA");

After:
  static_assert(is_convertible<A &&, B>::value, "AAA");

llvm-svn: 214075

While Clang now supports both ELFv1 and ELFv2 ABIs, their use is currently
hard-coded via the target triple: powerpc64-linux is always ELFv1, while
powerpc64le-linux is always ELFv2.

These are of course the most common scenarios, but in principle it is
possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on
little-endian systems (and GCC does support that), and there are some
special use cases for that (e.g. certain Linux kernel versions could
only be built using ELFv1 on LE).

This patch implements the Clang side of supporting this, based on the
LLVM commit 214072.  The command line options -mabi=elfv1 or -mabi=elfv2
select the desired ABI if present.  (If not, Clang uses the same default
rules as now.)

Specifically, the patch implements the following changes based on the
presence of the -mabi= option:

In the driver:
- Pass the appropiate -target-abi flag to the back-end
- Select the correct dynamic loader version (/lib64/ld64.so.[12])

In the preprocessor:
- Define _CALL_ELF to the appropriate value (1 or 2)

In the compiler back-end:
- Select the correct ABI in TargetInfo.cpp
- Select the desired ABI for LLVM via feature (elfv1/elfv2)

llvm-svn: 214074

llvm-svn: 214073

While LLVM now supports both ELFv1 and ELFv2 ABIs, their use is currently
hard-coded via the target triple: powerpc64-linux is always ELFv1, while
powerpc64le-linux is always ELFv2.

These are of course the most common scenarios, but in principle it is
possible to support the ELFv2 ABI on big-endian or the ELFv1 ABI on
little-endian systems (and GCC does support that), and there are some
special use cases for that (e.g. certain Linux kernel versions could
only be built using ELFv1 on LE).

This patch implements the LLVM side of supporting this.  As precedent
on other platforms suggests, ABI options are passed to the back-end as
features.  Thus, this patch implements two features "elfv1" and "elfv2"
that select the desired ABI if present.  (If not, the LLVM uses the
same default rules as now.)

llvm-svn: 214072

Before (with left pointer alignment):
  void f(int i = 0, SomeType* *temps = NULL);

After:
  void f(int i = 0, SomeType** temps = NULL);

llvm-svn: 214071

Before:
  int x = ~ * p;

After:
  int x = ~*p;

llvm-svn: 214070

Before:
  SomeFunction([](int i)LOCKS_EXCLUDED(a) {});

After:
  SomeFunction([](int i) LOCKS_EXCLUDED(a) {});

llvm-svn: 214069

MSC17 isn't capable to invoke other constructors in its scope.

llvm-svn: 214067