This won't always be enough info to call a virtual method from the
debugger, but it's a start.

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

Sibling patch to r272932:
http://reviews.llvm.org/rL272932


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

Re-apply r272900 - [OpenMP] Cast captures by copy when passed to fork call so that they are compatible to what the runtime library expects.

An issue in one of the regression tests was fixed for 32-bit hosts.


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

Revert r272900 - [OpenMP] Cast captures by copy when passed to fork call so that they are compatible to what the runtime library expects.

Was causing trouble in one of the regression tests for a 32-bit address space.


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

[OpenMP] Cast captures by copy when passed to fork call so that they are compatible to what the runtime library expects.

Summary:
This patch fixes an issue detected when firstprivate variables are passed to an OpenMP outlined function vararg list. Currently they are not compatible with what the runtime library expects causing malfunction in some targets.

This patch fixes the issue by moving the casting logic already in place for offloading to the common code that creates the outline function and arguments and updates the regression tests accordingly.

Reviewers: hfinkel, arpith-jacob, carlo.bertolli, kkwli0, ABataev

Subscribers: cfe-commits, caomhin

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

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

This is now supported for ARM, AArch64, PowerPC, SystemZ, SPARC, Mips.

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

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

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

buildbot to fail because of inaccurate CHECK in the test. This is a quick fix
for the test to make it platform independent.



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

This is the last patch required to support compilation for Intel MCU target (e.g. Intel(R) Quark(TM) micro controller D 2000).

When IAMCU triple is used:
 * Use IAMCU linker output format
 * Link with IAMCU crt objects
 * Link with IAMCU libraries

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


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

This is the second patch required to support compilation for Intel MCU target (e.g. Intel(R) Quark(TM) micro controller D 2000).
When IAMCU triple is used:
 * Recognize and use IAMCU GCC toolchain
 * Set up include paths
 * Forbid C++

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


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

clang/test/Driver/cuda-march.cu: Tweak not to match "clang" to other place like "path-to-clang-foo".

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

We implemented the mangling for this a long time ago.

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

Parameters and non-static members of aggregates are still excluded,
and probably should remain that way.

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


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

Summary:
Previously if you did e.g.

  $ clang -march=haswell -x cuda foo.cu

we would pass "-march=haswell -march=sm_20" down to the ptxas tool.
This causes it to assert, and rightly so!

Reviewers: tra

Subscribers: cfe-commits, echristo

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

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

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

Broken in r272717 because of no test coverage.

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

As noted in the code comment, a potential follow-on would be to remove
the builtins themselves. Other than ord/unord, this already works as 
expected. Eg:

  typedef float v4sf __attribute__((__vector_size__(16)));
  v4sf fcmpgt(v4sf a, v4sf b) { return a > b; }

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


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

Summary:
This patch is adding command-line support for the MSVC buffer security check.

The buffer security check is turned on with the '/GS' compiler switch.
https://msdn.microsoft.com/en-us/library/8dbf701c.aspx

The MSVC buffer security check in implemented here:
http://reviews.llvm.org/D20346

Reviewers: hans, rnk

Subscribers: chrisha, cfe-commits, rnk, hans, thakis

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

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

Patch by Lei Zhang.

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

Sibling patch to r272806:
http://reviews.llvm.org/rL272806


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

[Sparc] setjmp and longjmp intrinsic support update to add unit tests and remove accidentally checked-in code.

Related to revision r272782

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

added in the llvm patch is causing an assertion
to fail.


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

git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@272787 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

--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

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

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