This patch has the following changes
A new flag "-mhvx-length={64B|128B}" is introduced to specify the length of the vector.
Previously we have used "-mhvx-double" for 128 Bytes. This adds the target-feature "+hvx-length{64|128}b"

The "-mhvx" flag must be provided on command line to enable HVX for Hexagon. If no -mhvx-length flag
is specified, a default length is picked from the arch mentioned in this priority order from either -mhvx=vxx
or -mcpu. For v60 and v62 the default length is 64 Byte. For unknown versions, the length is 128 Byte. The 
-mhvx flag adds the target-feature "+hvxv{hvx_version}"

The 64 Byte mode is soon going to be deprecated. A warning is emitted if 64 Byte is enabled. A warning is
still emitted for the default 64 Byte as well. This warning can be suppressed with a -Wno flag.

The "-mhvx-double" and "-mno-hvx-double" flags are deprecated. A warning is emitted if the driver sees
them on commandline. "-mhvx-double" is an alias to "-mhvx-length=128B"

The compilation will error out if -mhvx-length is specified with out an -mhvx/-mhvx= flag

The macro HVX_LENGTH is defined and is set to the length of the vector. 
Eg: #define HVX_LENGTH 64

The macro HVX_ARCH is defined and is set to the version of the HVX. 
Eg: #define HVX_ARCH 62

Differential Revision: https://reviews.llvm.org/D38852


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

Enable support for the [[maybe_unused]] attribute from WG14 N2053 when enabling double square bracket attributes in C code.

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

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

Enable support for the [[fallthrough]] attribute from WG14 N2052 when enabling double square bracket attributes in C code.

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

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

instantiation, follow lexical parents not semantic ones: we want to find the
module where the pattern was written.


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

Darwin and OpenBSD are the only platforms which use `long int` for
`__INTPTR_TYPE__`.  The other platforms use `int` in 32-bit, and `long
int` on 64-bit (except for VMS and Windows which are LLP64).  Adjust the
type definitions to match the platform definitions.  We now generate the
same definition as GCC on all the targets.

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

The substitution for %debuginfo_tests had been inadvertently removed.
This adds it back.

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

The `IntPtrType` for Windows ARM should be `int` as per MSVC.  Adjust
the type accordingly.

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

Remove an option to use a reference type (on by default!) since a
non-reference type is always needed for creating expressions, functions
with multiple boolean parameters are very hard to use, and in general it
was just a booby trap for further crashes.
Furthermore, generalize call_once test case to fix some of the crashes mentioned
https://bugs.llvm.org/show_bug.cgi?id=34869
Also removes std::call_once crash.

Differential Revision: https://reviews.llvm.org/D39015

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

This is basically like r288207, just the other way round.


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

As reported here: https://bugs.llvm.org/show_bug.cgi?id=34973

"catch(...)" should catch EVERYTHING, even a rethrow. This
patch changes the order in which things are checked to ensure
that a '...' catch will get a rethrow.

Differential Revision: https://reviews.llvm.org/D39013


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

This test case was missing -fsyntax-only, so I've added it. NFC to the actual test contents, just how the test is executed.

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

Enable support for the [[nodiscard]] attribute from WG14 N2050 when enabling double square bracket attributes in C code.

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

Changes behavior introduced in r298369 to only error out on
vector component invalid length access on OpenCL mode.

Differential Revision: https://reviews.llvm.org/D38868

rdar://problem/33568748

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

If the variables is boolean and we generating inner function with real
types, the codegen may crash because of not loading boolean value from
memory.

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

This allows to return the static value that we know at compile time.

Differential Revision: https://reviews.llvm.org/D38968

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

Currently clang assumes the temporary variables emitted during
codegen of atomic builtins have address space 0, which
is not true for target triple amdgcn---amdgiz and causes invalid
bitcasts.

This patch fixes that.

Differential Revision: https://reviews.llvm.org/D38966


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

Differential Revision: https://reviews.llvm.org/D38796


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

A trailing deferred region isn't necessary in a function that ends with
this pattern:

  ...
  else {
    ...
    return;
  }

Special-case this pattern so that the closing curly brace of the
function isn't marked as uncovered. This issue came up in PR34962.

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

This makes it possible to view sub-line region counts for the l.h.s of
&& and || expressions in coverage reports.

It also fixes PR33465, which shows an example of incorrect coverage
output for an assignment statement containing '||'.

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

The nan family of math routines do not rely on global state.  They do
however depend on their parameter.  This fits the description of pure:
  Functions which have no effects except the return value and their
  return value depends only on the parameters and/or global variables.
Mark the family as `readonly`.

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

Summary: Previously, `VisitAttributes` was not called for function and class templates and thus their attributes were not accessible using libclang.

Reviewers: bkramer, arphaman, rsmith, jbcoe

Reviewed By: jbcoe

Subscribers: cfe-commits

Tags: #clang

Patch by jklaehn (Johann Klähn)

Differential Revision: https://reviews.llvm.org/D36955

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

This comes up when pre-processing standalone .s files containing
hash-prefixed comments. The pre-processor should skip the unknown
directive and not emit an extra newline as we were doing.

Fixes PR34950

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

GCC ignore qualifiers on array types. Since we seem to have this
function primarily for GCC compatibility, we should try to match that
behavior.

This also adds a few more test-cases __builtin_types_compatible_p,
which were inspired by GCC's documentation on the builtin.


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

This commit allows the refactoring library to use its own set of
refactoring-specific diagnostics to reports things like initiation errors.

Differential Revision: https://reviews.llvm.org/D38772


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

Summary:
The OS provides cross-dso CFI support starting with Android O.
Trapping mode does not require any runtime at all, and diagnostic mode
requires just ubsan-standalone.

Reviewers: pcc

Subscribers: srhines, cfe-commits

Differential Revision: https://reviews.llvm.org/D38908

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

The fixed commit ensures that ParsedSourceRange works correctly
with Windows paths.

Original message:

This commit actually brings clang-refactor to a usable state as it can now
apply the refactoring changes to source files.
The -selection option is now also fully supported.

Differential Revision: https://reviews.llvm.org/D38402


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

Currently all the consecutive bitfields are wrapped as a large integer unless there is unamed zero sized bitfield in between. The patch provides an alternative manner which makes the bitfield to be accessed as separate memory location if it has legal integer width and is naturally aligned. Such separate bitfield may split the original consecutive bitfields into subgroups of consecutive bitfields, and each subgroup will be wrapped as an integer. Now This is all controlled by an option -ffine-grained-bitfield-accesses. The alternative of bitfield access manner can improve the access efficiency of those bitfields with legal width and being aligned, but may reduce the chance of load/store combining of other bitfields, so it depends on how the bitfields are defined and actually accessed to choose when to use the option. For now the option is off by default.

Differential revision: https://reviews.llvm.org/D36562


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

If the user passes -nocudalib, we can live without it being present.
Simplify the code by just checking whether LibDeviceMap is empty.

Differential Revision: https://reviews.llvm.org/D38901

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

The first attempt, rL315614 was reverted because one libcxx
test broke, and i did not know at the time how to deal with it.

Summary:
Currently, clang only diagnoses completely out-of-range comparisons (e.g. `char` and constant `300`),
and comparisons of unsigned and `0`. But gcc also does diagnose the comparisons with the
`std::numeric_limits<>::max()` / `std::numeric_limits<>::min()` so to speak

Finally Fixes https://bugs.llvm.org/show_bug.cgi?id=34147
Continuation of https://reviews.llvm.org/D37565

Reviewers: rjmccall, rsmith, aaron.ballman

Reviewed By: rsmith

Subscribers: rtrieu, jroelofs, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D38101

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

The patch should have been checking against STDCXX17 not STDCXX14.

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

Patch by: daxpedda

Differential Revision: https://reviews.llvm.org/D38123

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

Add -f[no-]double-square-bracket-attributes as new driver options to control use of [[]] attributes in all language modes. This is the initial implementation of WG14 N2165, which is a proposal to add [[]] attributes to C2x, but also allows you to enable these attributes in C++98, or disable them in C++11 or later.

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

This patch implements an extension to the preprocessor:

__VA_OPT__(contents) --> which expands into its contents if variadic arguments are supplied to the parent macro, or behaves as an empty token if none.

  - Currently this feature is only enabled for C++2a (this could be enabled, with some careful tweaks, for other dialects with the appropriate extension or compatibility warnings)

  - The patch was reviewed here: https://reviews.llvm.org/D35782 and asides from the above (and moving some of the definition and expansion recognition logic into the corresponding state machines), I believe I incorporated all of Richard's suggestions.

A few technicalities (most of which were clarified through private correspondence between rsmith, hubert and thomas) are worth mentioning.  Given:

    #define F(a,...) a #__VA_OPT__(a ## a)  a ## __VA_OPT__(__VA_ARGS__)

    - The call F(,) Does not supply any tokens for the variadic arguments and hence VA_OPT behaves as a placeholder.
    - When expanding VA_OPT (for e.g. F(,1) token pasting occurs eagerly within its contents if the contents need to be stringified.
    - A hash or a hashhash prior to VA_OPT does not inhibit expansion of arguments if they are the first token within VA_OPT.
    - When a variadic argument is supplied, argument substitution occurs within the contents as does stringification - and these resulting tokens are inserted back into the macro expansions token stream just prior to the entire stream being rescanned and concatenated.

See wg21.link/P0306 for further details on the feature.


Acknowledgment: This patch would have been poorer if not for Richard Smith's usual thoughtful analysis and feedback.


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

Test is fixed in r315830


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

This is causing:
http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/43381

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

The warnings in libc++ tests were fixed in the meantime.

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

check-libcxx dislikes it.

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

In OpenCL the kernel function and non-kernel function has different calling conventions.
For certain targets they have different argument ABIs. Also kernels have special function
attributes and metadata for runtime to launch them.

The blocks passed to enqueue_kernel is supposed to be executed as kernels. As such,
the block invoke function should be emitted as kernel with proper calling convention and
argument ABI.

This patch emits enqueued block as kernel. If a block is both called directly and passed
to enqueue_kernel, separate functions will be generated.

Differential Revision: https://reviews.llvm.org/D38134


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