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@309976 91177308-0d34-0410-b5e6-96231b3b80d8

Patch by ~paul (cynecx on phabricator)! Some test massaging by me.


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

Patch by: Reka Nikolett Kovacs


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

Bot failure:
http://lab.llvm.org:8011/builders/clang-sphinx-docs/builds/12043/steps/docs-clang-html/logs/stdio

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

In r309007, I made -fsanitize=null a hard prerequisite for -fsanitize=vptr. I
did not see the need for the two checks to have separate null checking logic
for the same pointer. I expected the two checks to either always be enabled
together, or to be mutually compatible.

In the mailing list discussion re: r309007 it became clear that that isn't the
case. If a codebase is -fsanitize=vptr clean but not -fsanitize=null clean,
it's useful to have -fsanitize=vptr emit its own null check. That's what this
patch does: with it, -fsanitize=vptr can be used without -fsanitize=null.

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

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

Originally, we weren't able to match on Type nodes themselves (only QualType),
so the hasDeclaration matcher was initially written to give what we thought are
reasonable results for QualType matches.

When we chagned the matchers to allow matching on Type nodes, it turned out
that the hasDeclaration matcher was by chance written templated enough to now
allow hasDeclaration to also match on (some) Type nodes.

This patch change the hasDeclaration matcher to:
a) work the same on Type and QualType nodes,
b) be completely explicit about what nodes we can match instead of just allowing
   anything with a getDecl() to match,
c) explicitly control desugaring only one level in very specific instances.
d) adds hasSpecializedTemplate and tagType matchers to allow migrating
  existing use cases that now need more explicit matchers

Note: This patch breaks clang-tools-extra. The corresponding patch there
is approved and will land in a subsequent patch.

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

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

The additions in r309562 triggered a docs buildbot failure.


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

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

On some targets, passing zero to the clz() or ctz() builtins has undefined
behavior. I ran into this issue while debugging UB in __hash_table from libcxx:
the bug I was seeing manifested itself differently under -O0 vs -Os, due to a
UB call to clz() (see: libcxx/r304617).

This patch introduces a check which can detect UB calls to builtins.

llvm.org/PR26979

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

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

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

The instrumentation generated by -fsanitize=vptr does not null check a
user pointer before loading from it. This causes crashes in the face of
UB member calls (this=nullptr), i.e it's causing user programs to crash
only after UBSan is turned on.

The fix is to make run-time null checking a prerequisite for enabling
-fsanitize=vptr, and to then teach UBSan to reuse these run-time null
checks to make -fsanitize=vptr safe.

Testing: check-clang, check-ubsan, a stage2 ubsan-enabled build

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

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

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

... in the few remaining places where this was not corrected.


  


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

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

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

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

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

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

documentation.

Trying to match integerLiteral(-1) will silently fail, because an numeric
literal is always positive.
- Update the documentation to explain how to match negative numeric
  literals.
- Add a unit test.

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

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

Reviewers: pcc

Subscribers: llvm-commits

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

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

Summary: The Clang option was previously not included in the User's Manual.

Reviewers: anemet, davidxl, hfinkel

Reviewed By: hfinkel

Subscribers: cfe-commits

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

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

Summary:
This way, the behavior of that warning flag
more closely resembles that of GCC.

Do note that there is at least one false-negative (see FIXME in tests).

Fixes PR4802.

Testing:
```
ninja check-clang-sema check-clang-semacxx
```

Reviewers: dblaikie, majnemer, rnk

Reviewed By: dblaikie, rnk

Subscribers: mclow.lists, cfe-commits, alexfh, rnk

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

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

-fslp-vectorize-aggressive and -fno-slp-vectorize-aggressive flags back
under this group and test for the warning. Document the future removal
in the ReleaseNotes.

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


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

Summary:
Un-revert https://reviews.llvm.org/D34868, but with a slight tweak to the
documentation to fix an error -- I had used the wrong syntax for a link.



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

Summary:
The commit caused a documentation breakage.



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

Summary:
Depends on https://reviews.llvm.org/D34867.

Add a Clang frontend option to enable optimization remark hotness
thresholds, which were added to LLVM in https://reviews.llvm.org/D34867.
This prevents diagnostics that do not meet a minimum hotness
threshold from being output. When generating optimization remarks for large
codebases with a ton of cold code paths, this option can be used
to limit the optimization remark output at a reasonable size.
Discussion of this change can be read here:
http://lists.llvm.org/pipermail/llvm-dev/2017-June/114377.html

Reviewers: anemet, davidxl, hfinkel

Reviewed By: anemet

Subscribers: fhahn, cfe-commits

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

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

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

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

This is useful when an upper limit on the cache size needs to be
controlled independently of the amount of the amount of free space.

One use case is a machine with a large number of cache directories
(e.g. a buildbot slave hosting a large number of independent build
jobs). By imposing an upper size limit on each cache directory,
users can more easily estimate the server's capacity.

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

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

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

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

Summary:
This patch adds a `SortUsingDeclaration` style option and enables it for llvm
style.

Reviewers: klimek

Reviewed By: klimek

Subscribers: klimek

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

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

Summary:
This updates the format options documentation script to indent the
documentation of nested fields. The previous format caused some problems,
as when a bulleted list ends with a multiline comment. See the buildbot failure
http://lab.llvm.org:8011/builders/clang-sphinx-docs/builds/10020/steps/docs-clang-html/logs/stdio

Reviewers: djasper

Reviewed By: djasper

Subscribers: cfe-commits

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

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

Summary: Style documentation is generated automatically by `docs/tools/dump_format_style.py`. This hasn't been ran for a while.

Reviewers: djasper

Subscribers: cfe-commits, klimek

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

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

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

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

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

With this patch, one can configure a BufWrite hook that will make the
clang-format integration compute a diff of the current buffer with the file
that's on disk and format all changed lines. This should create a
zero-overhead auto-format solution that doesn't require the file to
already be clang-format clean to avoid spurious diffs.

Review: https://reviews.llvm.org/D32429

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

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