Changes by
  Matt Arsenault
  Konstantin Zhuravlyov

llvm-svn: 331216

Now that constant merging is off by default, we'd like a way to enable
it on Windows.

llvm-svn: 331214

We should not emit warning that the parameters are not marked as declare
target, these declaration are local and cannot be marked as declare
target.

llvm-svn: 331211

As suggested in the post-commit thread for rL331056, we should match these 
clang options with the established vocabulary of the corresponding sanitizer
option. Also, the use of 'strict' is well-known for these kinds of knobs, 
and we can improve the descriptive text in the docs.

So this intends to match the logic of D46135 but only change the words.
Matching LLVM commit to match this spelling of the attribute to follow shortly.

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

llvm-svn: 331209

Backported a minor fix to the comment in the header.

llvm-svn: 331207

Non-static member functions should not be emitted as a standalone
functions, this leads to compiler crash.

llvm-svn: 331206

Emit error messages instead of compiler crashing when the target region
does not exist in the device code + fix crash when the location comes
from macros.

llvm-svn: 331195

llvm-svn: 331177

llvm-svn: 331176

Summary:
The getConstraintRegister method is used by semantic checking of
inline assembly statements in order to diagnose conflicts between
clobber list and input/output lists. Currently ARM and AArch64 don't
override getConstraintRegister, so conflicts between registers
assigned to variables in asm labels and clobber lists are not
diagnosed. Such conflicts can cause assertion failures in the back end
and even miscompilations.

This patch implements getConstraintRegister for ARM and AArch64
targets. Since these targets don't have single-register constraints,
the implementation is trivial and just returns the register specified
in an asm label (if any).

Reviewers: eli.friedman, javed.absar, thopre

Reviewed By: thopre

Subscribers: rengolin, eraman, rogfer01, myatsina, kristof.beyls, cfe-commits, chrib

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

llvm-svn: 331164

When a '>>' token is split into two '>' tokens (in C++11 onwards), or (as an
extension) when we do the same for other tokens starting with a '>', we can't
just use a location pointing to the first '>' as the location of the split
token, because that would result in our miscomputing the length and spelling
for the token. As a consequence, for example, a refactoring replacing 'A<X>'
with something else would sometimes replace one character too many, and
similarly diagnostics highlighting a template-id source range would highlight
one character too many.

Fix this by creating an expansion range covering the first character of the
'>>' token, whose spelling is '>'. For this to work, we generalize the
expansion range of a macro FileID to be either a token range (the common case)
or a character range (used in this new case).

llvm-svn: 331155

llvm-svn: 331152

Previously we would sometimes print these as 'T &&&' or even 'T &&&&'.

llvm-svn: 331137

Clang incorrectly applied the packed attribute to base classes. Per GCC's
documentation and as can be observed from its behavior, packed only applies to
members, not base classes.

This change is conditioned behind -fclang-abi-compat so that an ABI break can
be avoided by users if desired.

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

llvm-svn: 331136

Found by opening config.h.cmake in vim, finding all defined macros with

  /define\(01\)\? \zs[A-Za-z0-9_]*<cr>
  :%s//\=setreg('A', submatch(0), 'V')/gn<cr>
  :put A<cr>

and then joining them all with |, and passing that to

  git grep -E that_pattern 'clang/*.h' 'clang/*.cpp' 'clang/*.c'

and diffing that output with the result of

  git grep Config/config.h 'clang/*.h' 'clang/*.cpp' 'clang/*.c'

No intended behavior change.

llvm-svn: 331124

We still support the old mangling if we're trying to be ABI-compatible with
Clang 6.0, though.

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

llvm-svn: 331098

Patch by David Carlier!

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

llvm-svn: 331096

llvm-svn: 331093

API list and improved warning text composed by Devin Coughlin.

llvm-svn: 331089

Speculative. ClangMoveTests started failing on
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/9958
after this change. I can't reproduce on my machine, let's see
if it was due to this change.

llvm-svn: 331077

LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too.  Just use the
default macro instead of a reinvented one.

See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.

llvm-svn: 331069

Summary:
Previously, we checked tokens for `tok::identifier` to see if they
were identifiers inside an Objective-C selector.

However, this missed C++ keywords like `new` and `delete`.

To fix this, this diff uses `getIdentifierInfo()` to find
identifiers or keywords inside Objective-C selectors.

Test Plan: New tests added. Ran tests with:
  % make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests

Reviewers: djasper, jolesiak

Reviewed By: djasper

Subscribers: klimek, cfe-commits

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

llvm-svn: 331067

During deserialization clang is currently missing the merging of
protocols into the canonical interface for the class extension.

This merging only currently happens during parsing and should also
be considered during deserialization.

rdar://problem/38724303

llvm-svn: 331063

llvm-svn: 331057

This option was added with:
D46135
rL331041
...copying the text from UsersManual.rst for more exposure.

llvm-svn: 331056

llvm-svn: 331055

llvm-svn: 331053

llvm-svn: 331052

llvm-svn: 331048

As discussed in the post-commit thread for:
rL330437 ( http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20180423/545906.html )

We need a way to opt-out of a float-to-int-to-float cast optimization because too much 
existing code relies on the platform-specific undefined result of those casts when the 
float-to-int overflows.

The LLVM changes associated with adding this function attribute are here:
rL330947
rL330950
rL330951

Also as suggested, I changed the LLVM doc to mention the specific sanitizer flag that 
catches this problem:
rL330958

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

llvm-svn: 331041

The ACLE spec which describes these intrinsics hasn't been published yet, but
this is based on the final draft which will be published soon, and these have
already been implemented by GCC.

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

llvm-svn: 331039

This adds a pre-defined macro to test if the compiler has support for the
v8.2-A dot rpoduct intrinsics in AArch32 mode.

The AAcrh64 equivalent has already been added by rL330229.

The ACLE spec which describes this macro hasn't been published yet, but this is
based on the final internal draft, and GCC has already implemented this.

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

llvm-svn: 331038

SPIR-V encodes the read_only and write_only access qualifiers of pipes,
so separate LLVM IR types are required to target SPIR-V.  Other backends
may also find this useful.

These new types are `opencl.pipe_ro_t` and `opencl.pipe_wo_t`, which
replace `opencl.pipe_t`.

This replaces __get_pipe_num_packets(...) and __get_pipe_max_packets(...)
which took a read_only pipe with separate versions for read_only and
write_only pipes, namely:

 * __get_pipe_num_packets_ro(...)
 * __get_pipe_num_packets_wo(...)
 * __get_pipe_max_packets_ro(...)
 * __get_pipe_max_packets_wo(...)

These separate versions exist to avoid needing a bitcast to one of the
two qualified pipe types.

Patch by Stuart Brady.

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

llvm-svn: 331026

Summary:
This patch moves the MultiplexASTDeserializationListener declaration into a public header.

We're currently using this multiplexer in the cling interpreter to attach another
ASTDeserializationListener during the execution (so, after the MultiplexConsumer is already
attached which prevents us from attaching more). So far we're doing this by patching clang
and making this class public, but it makes things easier if we make this instead just public in
upstream.

Reviewers: thakis, v.g.vassilev, rsmith, bruno

Reviewed By: bruno

Subscribers: llvm-commits, cfe-commits, v.g.vassilev

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

llvm-svn: 331021

function if a function delegates to another function.

Fix a bug introduced in r328731, which caused a struct with ObjC __weak
fields that was passed to a function to be destructed twice, once in the
callee function and once in another function the callee function
delegates to. To prevent this, keep track of the callee-destructed
structs passed to a function and disable their cleanups at the point of
the call to the delegated function.

This reapplies r331016, which was reverted in r331019 because it caused
an assertion to fail in EmitDelegateCallArg on a windows bot. I made
changes to EmitDelegateCallArg so that it doesn't try to deactivate
cleanups for structs that have trivial destructors (cleanups for those
structs are never pushed to the cleanup stack in EmitParmDecl).

rdar://problem/39194693

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

llvm-svn: 331020

This reverts commit r331016, which broke a windows bot.

http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/11727

llvm-svn: 331019

llvm-svn: 331017

function if a function delegates to another function.

Fix a bug introduced in r328731, which caused a struct with ObjC __weak
fields that was passed to a function to be destructed twice, once in the
callee function and once in another function the callee function
delegates to. To prevent this, keep track of the callee-destructed
structs passed to a function and disable their cleanups at the point of
the call to the delegated function.

rdar://problem/39194693

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

llvm-svn: 331016

Avoid crash when the sub-expression of operator delete[] is of array type.

This is not the same as simply using a delete[] syntax.

We're still not properly calling destructors in this case in the analyzer.

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

llvm-svn: 331014

template arguments.

This fixes some cases where we'd incorrectly accept "A::template B" when B is a
kind of template that requires template arguments (in particular, a variable
template or a concept).

llvm-svn: 331013