git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272787 91177308-0d34-0410-b5e6-96231b3b80d8

[Sparc] Change to let clang know that setjmp and longjmp intrinsics are implemented in the back-end.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272782 91177308-0d34-0410-b5e6-96231b3b80d8

Patch adds intrinsics for mrrc/mrrc2. The
intrinsics for mrrc/mrrc2 return a single
uint64_t to represent two 32 bit values.

The mcrr/mcrr2 intrinsic was changed to
accept a single uint64_t instead of two
32 bit values as the input for consistency.

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



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272777 91177308-0d34-0410-b5e6-96231b3b80d8

This reverts commit 02536057.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272776 91177308-0d34-0410-b5e6-96231b3b80d8

instantiation.

Added checks for non-dependent context when trygin to capture
non-constant schedule chunk expression for proper codegen of outlined
functions.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272775 91177308-0d34-0410-b5e6-96231b3b80d8

classes.

MSVC actively uses unqualified lookup in dependent bases, lookup at the
instantiation point (non-dependent names may be resolved on things
declared later) etc. and all this stuff is the main cause of
incompatibility between clang and MSVC.

Clang tries to emulate MSVC behavior but it may fail in many cases.
clang could store lexed tokens for member functions definitions within
ClassTemplateDecl for later parsing during template instantiation.

It will allow resolving many possible issues with lookup in dependent
base classes and removing many already existing MSVC-specific
hacks/workarounds from the clang code.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272774 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272755 91177308-0d34-0410-b5e6-96231b3b80d8

Earlier versions of MSVC did not include inttypes.h.  Ensure that we dont try to
include_next on those releases.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272741 91177308-0d34-0410-b5e6-96231b3b80d8

--dependent-lib arguments for the sanitizer libraries must be emitted when
coverage is enabled w/o any sanitizers.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272735 91177308-0d34-0410-b5e6-96231b3b80d8

Reviewed as part of http://reviews.llvm.org/D20444

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272720 91177308-0d34-0410-b5e6-96231b3b80d8

The reason is that this (a) seems to work just fine and (b) useful when building stuff with
sanitizer+coverage, but need to exclude the sanitizer for a particular source file.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272717 91177308-0d34-0410-b5e6-96231b3b80d8

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272710 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272702 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272701 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272699 91177308-0d34-0410-b5e6-96231b3b80d8

After r272599, -DLLVM_BUILD_INSTRUMENTED passes a default argument to
-fprofile-instr-generate. This confuses the perf-helper script because
the runtime emits a note stating that the default is overridden by the
LLVM_PROFILE_FILE environment variable.

Change the perf-helper script s.t it does not treat these notes as
failures.

This isn't a strictly NFC change, but I don't see a simple way to add a
test for it.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272695 91177308-0d34-0410-b5e6-96231b3b80d8

Summary: do not add existing includes.

Reviewers: djasper

Subscribers: klimek, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272669 91177308-0d34-0410-b5e6-96231b3b80d8

Before, this could be formatted at all (with BracketAlignmentStyle
AlwaysBreak):

  foo = <Bar[]>[
    1, /* */
    2
  ];

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272668 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272667 91177308-0d34-0410-b5e6-96231b3b80d8

The two patches together enable clang to support targets like
"x86_64-pc-linux-musl" and build binaries against musl-libc instead of
glibc. This make it easy for clang to work on some musl-based systems
like Alpine Linux and certain flavors of Gentoo.

Patch by Lei Zhang.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272662 91177308-0d34-0410-b5e6-96231b3b80d8

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272658 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This is similar to other loop pragmas like 'vectorize'.  Currently it
only has state values: distribute(enable) and distribute(disable).  When
one of these is specified the corresponding loop metadata is generated:

  !{!"llvm.loop.distribute.enable", i1 true/false}

As a result, loop distribution will be attempted on the loop even if
Loop Distribution in not enabled globally.  Analogously, with 'disable'
distribution can be turned off for an individual loop even when the pass
is otherwise enabled.

There are some slight differences compared to the existing loop pragmas.

1. There is no 'assume_safety' variant which makes its handling slightly
different from 'vectorize'/'interleave'.

2. Unlike the existing loop pragmas, it does not have a corresponding
numeric pragma like 'vectorize' -> 'vectorize_width'.  So for the
consistency checks in CheckForIncompatibleAttributes we don't need to
check it against other pragmas.  We just need to check for duplicates of
the same pragma.

Reviewers: rsmith, dexonsmith, aaron.ballman

Subscribers: bob.wilson, cfe-commits, hfinkel

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272656 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272654 91177308-0d34-0410-b5e6-96231b3b80d8

This new diagnostic is causing some false positives that have to be addressed.

This reverts commit 272552




git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272653 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
The validity of ABI/CPU pairs is no longer checked on the fly but is
instead checked after initialization. As a result, invalid CPU/ABI pairs
can be reported as being known but invalid instead of being unknown. For
example, we now emit:
  error: ABI 'n32' is not supported on CPU 'mips32r2'
instead of:
  error: unknown target ABI 'n64'

Reviewers: atanasyan

Subscribers: sdardis, cfe-commits

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272645 91177308-0d34-0410-b5e6-96231b3b80d8

See https://llvm.org/bugs/show_bug.cgi?id=28100.

In r266561 when I implemented allowing explicit specializations of function templates to override deleted status, I mistakenly assumed (and hence introduced a violable assertion) that when an explicit specialization was being declared, the corresponding specialization of the most specialized function template that it would get linked to would always be the one that was implicitly generated - and so if it was marked as 'deleted' it must have inherited it from the primary template and so should be safe to reset its deleted status, and set it to being an explicit specialization.  Obviously during redeclaration of a deleted explicit specialization, in order to avoid a recursive reset, we need to check that the previous specialization is not an explicit specialization (instead of assuming and asserting it) and that it hasn't been referenced, and so only then is it safe to reset its 'deleted' status.

All regression tests pass.

Thanks to Zhendong Su for reporting the bug and David Majnemer for tracking it to my commit r266561, and promptly bringing it to my attention.





git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272631 91177308-0d34-0410-b5e6-96231b3b80d8

Support certain MS pragmas right after the closing curly brace of a
class.  Clang did not expect __pragma in this position.

This fixes PR28094.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272628 91177308-0d34-0410-b5e6-96231b3b80d8

If definition of default function argument uses itself, clang crashed,
because corresponding function parameter is not associated with the default
argument yet. With this fix clang emits appropriate error message.

This change fixes PR28105.

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


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272623 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272610 91177308-0d34-0410-b5e6-96231b3b80d8

pointer-to-pointer representing the parameter. An aggregate rvalue representing
a pointer does not make sense.

We got away with this weirdness because CGCall happens to blindly load an
RValue in aggregate form in this case, without checking whether an RValue for
the type should be in scalar or aggregate form.


git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272609 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272605 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272604 91177308-0d34-0410-b5e6-96231b3b80d8

Patch for r272584 (http://reviews.llvm.org/rL272584) to address clang-x64-ninja-win7 buildbot failure.

Patch by Eric Niebler



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272592 91177308-0d34-0410-b5e6-96231b3b80d8

ActOnBinOp corrects delayed typos when in C mode; don't correct them in that
case. Fixes PR26700.

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272587 91177308-0d34-0410-b5e6-96231b3b80d8

Use the name of the file on disk to issue a new diagnostic about non-portable #include and #import paths.

Differential Revision: http://reviews.llvm.org/D19843
Corresponding LLVM change: http://reviews.llvm.org/D19842

Re-commit of r272562 after addressing clang-x86-win2008-selfhost failure.



git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272584 91177308-0d34-0410-b5e6-96231b3b80d8

It's useful e.g. for distributed build systems.

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272583 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272575 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272573 91177308-0d34-0410-b5e6-96231b3b80d8

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272572 91177308-0d34-0410-b5e6-96231b3b80d8

Summary:
This patch introduces the concept of offloading tool chain and offloading kind. Each tool chain may have associated an offloading kind that marks it as used in a given programming model that requires offloading. 

It also adds the logic to iterate on the tool chains based on the kind. Currently, only CUDA is supported, but in general a programming model (an offloading kind) may have associated multiple tool chains that require supporting offloading.

This patch does not add tests - its goal is to keep the existing functionality.

This patch is the first of a series of three that attempts to make the current support of CUDA more generic and easier to extend to other programming models, namely OpenMP. It tries to capture the suggestions/improvements/concerns on the initial proposal in  http://lists.llvm.org/pipermail/cfe-dev/2016-February/047547.html. It only tackles the more consensual part of the proposal, i.e.does not address the problem of intermediate files bundling yet.

Reviewers: ABataev, jlebar, echristo, hfinkel, tra

Subscribers: guansong, Hahnfeld, andreybokhanko, tcramer, mkuron, cfe-commits, arpith-jacob, carlo.bertolli, caomhin

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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272571 91177308-0d34-0410-b5e6-96231b3b80d8