This behaves similar to the __has_cpp_attribute builtin macro in that it allows users to detect whether an attribute is supported with the [[]] spelling syntax, which can be enabled in C with -fdouble-square-bracket-attributes.

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

This documents the differences/interactions between _Float16 and __fp16
and is a companion change for the _Float16 type implementation (r312794).

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


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

OpenCL 2.0 atomic builtin functions have a scope argument which is ideally
represented as synchronization scope argument in LLVM atomic instructions.

Clang supports translating Clang atomic builtin functions to LLVM atomic
instructions. However it currently does not support synchronization scope
of LLVM atomic instructions. Without this, users have to use LLVM assembly
code to implement OpenCL atomic builtin functions.

This patch adds OpenCL 2.0 atomic builtin functions as Clang builtin
functions, which supports generating LLVM atomic instructions with
synchronization scope operand.

Currently only constant memory scope argument is supported. Support of
non-constant memory scope argument will be added later.

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


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

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

https://reviews.llvm.org/D35379


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

This patch provides a means to specify section-names for global variables, 
functions and static variables, using #pragma directives. 
This feature is only defined to work sensibly for ELF targets.
One can specify section names as:
#pragma clang section bss="myBSS" data="myData" rodata="myRodata" text="myText"
One can "unspecify" a section name with empty string e.g.
#pragma clang section bss="" data="" text="" rodata=""

Reviewers: Roger Ferrer, Jonathan Roelofs, Reid Kleckner
Differential Revision: https://reviews.llvm.org/D33412



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

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

This is a recommit of r300539 that was reverted in r300543 due to test failures.
The original commit message is displayed below:

The new '#pragma clang attribute' directive can be used to apply attributes to
multiple declarations. An attribute must satisfy the following conditions to
be supported by the pragma:
- It must have a subject list that's defined in the TableGen file.
- It must be documented.
- It must not be late parsed.
- It must have a GNU/C++11 spelling.

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


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

Some tests fail on the Windows buildbots. I will have to investigate more.
This commit reverts r300539, r300540 and r300542.


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

The new '#pragma clang attribute' directive can be used to apply attributes to
multiple declarations. An attribute must satisfy the following conditions to
be supported by the pragma:
- It must have a subject list that's defined in the TableGen file.
- It must be documented.
- It must not be late parsed.
- It must have a GNU/C++11 spelling.

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


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

Summary:
[LWG 2911](http://cplusplus.github.io/LWG/lwg-defects.html#2911) adds `std::is_aggregate` to the library, which requires a new builtin trait. This patch implements `__is_aggregate`.


Reviewers: rsmith, majnemer, aaron.ballman

Reviewed By: aaron.ballman

Subscribers: STL_MSFT, cfe-commits

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

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

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

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

This adds the new pragma and the first variant, contract(on/off/fast).

The pragma has the same block scope rules as STDC FP_CONTRACT, i.e. it can be
placed at the beginning of a compound statement or at file scope.

Similarly to STDC FP_CONTRACT there is no need to use attributes.  First an
annotate token is inserted with the parsed details of the pragma.  Then the
annotate token is parsed in the proper contexts and the Sema is updated with
the corresponding FPOptions using the shared ActOn function with STDC
FP_CONTRACT.

After this the FPOptions from the Sema is propagated into the AST expression
nodes.  There is no change here.

I was going to add a 'default' option besides 'on/off/fast' similar to STDC
FP_CONTRACT but then decided against it. I think that we'd have to make option
uppercase then to avoid using 'default' the keyword.  Also because of the
scoped activation of pragma I am not sure there is really a need a for this.

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

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

The alias was only ever used on darwin and had some issues there,
and isn't used in practice much. Also fixes a problem with -mno-altivec
not turning off -maltivec.

Also add a diagnostic for faltivec/fno-altivec that directs users to use
maltivec options and include the altivec.h file explicitly.

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

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

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

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

Summary:
With this commit simple coroutines can be created in plain C using coroutine builtins.

Reviewers: rnk, EricWF, rsmith

Subscribers: modocache, mgorny, mehdi_amini, beanz, cfe-commits

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

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

It's complaining that it couldn't lex a compiler warning as C++. I don't
blame it.


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

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

MSVC now supports the __is_assignable type trait intrinsic,
to enable easier and more efficient implementation of the
Standard Library's is_assignable trait.
As of Visual Studio 2015 Update 3, the VC Standard Library
implementation uses the new intrinsic unconditionally.

The implementation is pretty straightforward due to the previously
existing is_nothrow_assignable and is_trivially_assignable.
We handle __is_assignable via the same code as the other two except
that we skip the extra checks for nothrow or triviality.

Patch by Dave Bartolomeo!

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

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

The change reflects llvm r268431.

Patch by Michael Lemay (michael.lemay@intel.com)

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


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

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

Also add documentation for bitreverse builtins

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

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

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

These were implemented back in r244564.  However, I forgot to update the
docs.

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

Patch by David Grayson!

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

Summary:
In r247104 I added the builtins for generating non-temporal memory operations,
but now I realized that they lack documentation. This patch adds some.

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

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

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

This patch depends on r246688 (D12341).

The goal is to make LLVM generate different code for these functions for a target that
has cheap branches (see PR23827 for more details):

int foo();

int normal(int x, int y, int z) {
   if (x != 0 && y != 0) return foo();
   return 1;
}

int crazy(int x, int y) {
   if (__builtin_unpredictable(x != 0 && y != 0)) return foo();
   return 1;
}

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



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

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

This change adds the new unroll metadata "llvm.loop.unroll.enable" which directs
the optimizer to unroll a loop fully if the trip count is known at compile time, and
unroll partially if the trip count is not known at compile time. This differs from
"llvm.loop.unroll.full" which explicitly does not unroll a loop if the trip count is not
known at compile time

With this change "#pragma unroll" generates "llvm.loop.unroll.enable" rather than
"llvm.loop.unroll.full" metadata. This changes the semantics of "#pragma unroll" slightly
to mean "unroll aggressively (fully or partially)" rather than "unroll fully or not at all".

The motivating example for this change was some internal code with a loop marked
with "#pragma unroll" which only sometimes had a compile-time trip count depending
on template magic. When the trip count was a compile-time constant, everything works
as expected and the loop is fully unrolled. However, when the trip count was not a
compile-time constant the "#pragma unroll" explicitly disabled unrolling of the loop(!).
Removing "#pragma unroll" caused the loop to be unrolled partially which was desirable
from a performance perspective.



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

Support for emitting libcalls for __atomic_fetch_nand and
__atomic_{add,sub,and,or,xor,nand}_fetch was missing; add it, and some
test cases.

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

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

This change updates the documentation for the loop unrolling pragma behavior
change in r242047. Specifically, with that change "#pragma unroll" will not
unroll loops with a runtime trip count.



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

Protection against stack-based memory corruption errors using SafeStack: Clang command line option and function attribute

This patch adds the -fsanitize=safe-stack command line argument for clang,
which enables the Safe Stack protection (see http://reviews.llvm.org/D6094
for the detailed description of the Safe Stack).

This patch is our implementation of the safe stack on top of Clang. The
patches make the following changes:

- Add -fsanitize=safe-stack and -fno-sanitize=safe-stack options to clang
  to control safe stack usage (the safe stack is disabled by default).

- Add __attribute__((no_sanitize("safe-stack"))) attribute to clang that can be
  used to disable the safe stack for individual functions even when enabled
  globally.

Original patch by Volodymyr Kuznetsov and others at the Dependable Systems
Lab at EPFL; updates and upstreaming by myself.

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

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

Fixes PR18985

Patch by Vassil Vassilev!

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

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