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

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

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

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

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

llvm-svn: 331093

API list and improved warning text composed by Devin Coughlin.

llvm-svn: 331089

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

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

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

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

when compiling the kernel or kexts.

Destructors should be registered with atexit by default only when we are
compiling userland code.

llvm-svn: 331010

The LLVM commit introduces a crash in LLVM's instruction selection.

I filed http://llvm.org/PR37260 with the test case.

llvm-svn: 330997

[X86] Make __builtin_ia32_readeflags_u32 and __builtin_ia32_writeeflags_u32 only available on 32-bit targets.

These builtins can't be handled by the backend on 64-bit targets. So error up front instead of throwing an isel error.

Fixes PR37225

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

llvm-svn: 330987

llvm-svn: 330927

Implementation of `InputArgList` assumes its field `ArgStrings` contains
strings for each argument exactly in the same order. This condition was
broken when arguments from config file and from invocation were merged.

This change fixes https://bugs.llvm.org/show_bug.cgi?id=37196 (Clang
config files can crash argument handling).

llvm-svn: 330926

On AVX512F targets we'll produce an emulated sequence using 3 pmuludqs with shifts and adds. On AVX512DQ we'll use vpmulld.

Fixes PR37140.

llvm-svn: 330923

a preceding 'template' keyword.

We only diagnose in the dependent case (wherein we used to crash). Another bug
prevents the diagnostic from appearing in the non-template case.

llvm-svn: 330894

In passing, add 'concept' to the list of template kinds in diagnostics.

llvm-svn: 330890

See Richard's humbling feedback here: 
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226482.html
http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180423/226486.html

Wish I'd had the patience to solicit the feedback prior to committing :)

Sorry for the noise guys.

Thank you Richard for being the steward that clang deserves!

llvm-svn: 330888

If 'A' is a C++ aggregate with a reference field of type 'C', in code like
  A a = { C() };
C() is lifetime-extended by 'a'. The analyzer wasn't expecting this pattern and
crashing. Additionally, destructors aren't added in the CFG for this case,
so for now we shouldn't be inlining the constructor for C().

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

llvm-svn: 330882

template argument list.

llvm-svn: 330881

Supporting additional rules for parsing ISA string.

- RISC-V ISA strings must be lowercase.
E.g.: rv32IMC is not supported, rv32imc is correct.

- Multi-letter extensions are to be separated by a single
underscore '_'. The extension prefix counts as a letter.
This means extensions that start with 's', 'sx' and 'sx'
are all multi-letter.
E.g.:
xasb is a single non-standard extension named 'xasb'
xa_sb are two extensions, the non-standard user level extension
'xa', and the supervisor level extension 'sb'.

- Standard user-level extensions are specified following
a canonical order, according to Table 22.1 in
RISC-V User-Level ISA V2.2.

- Non-standard user-level 'x' extensions,
standard supervisor-level 's' extensions and
non-standard supervisor-level 'sx' extensions
are also specified following a canonical order according
to Table 22.1 in RISC-V User-Level ISA V2.2:
'x' extensions, follwed by 's' extensions and then 'sx' extensions.

- Extensions might have a version number.
Underscores may be used to separate ISA subset components to
improve readability and to provide disambiguation.
E.g.: rv32i2_m3_a1_f2_d2

- Version numbers are divided into major and minor numbers,
separated by a 'p'. If the minor version is 0, then 'p0' can
be omitted.

- Additional checks for dependent extensions and invalid
extensions combinations.
E.g.:
'e' requires rv32
'e' can't be combined with 'f' nor 'd'
'q' requires rv64

- TODO items have also been marked with comments in the code.

Reviewers: asb, kito-cheng

Reviewed By: asb

Subscribers: edward-jones, mgrang, zzheng, rbar, johnrusso, simoncook, jordy.potman.lists, sabuasal, niosHD, shiva0217, cfe-commits

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

llvm-svn: 330880

with non-simulator SDKs

rdar://37955008

llvm-svn: 330878

Normally the analyzer begins path-sensitive analysis from functions within
the main file, even though the path is allowed to go through any functions
within the translation unit.

When a recent version of WebKit is compiled, the "unified sources" technique
is used, that assumes #including multiple code files into a single main file.
Such file would have no functions defined in it, so the analyzer wouldn't be
able to find any entry points for path-sensitive analysis.

This patch pattern-matches unified file names that are similar to those
used by WebKit and allows the analyzer to find entry points in the included
code files. A more aggressive/generic approach is being planned as well.

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

llvm-svn: 330876

Fixed directory separators in tests to be compatible with both
Windows and !Windows.

This reverts commit aa423850afa4c16a53c4c492fe254dcad3d5a53e.

llvm-svn: 330873

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

llvm-svn: 330872

If -no-canonical-prefixes isn't used, the clang executable name used
is the one of the actual executable, not the name of the symlink that
the user invoked.

In these cases, the target prefix was overridden based on the clang
executable name. (On the other hand the implicit -target option
that such a symlink adds, is added as an actual command line parameter
in tools/driver/driver.cop, before resolving the symlink and finding
the actual clang executable.

Use the original ClangNameParts (set from argv[0] in
tools/driver/driver.cpp) if it seems to be initialized propery.

All existing tests of this feature used -no-canonical-prefixes
(possibly because it also makes the driver look in the directory
of the symlink instead of the directory of the executable); add
another one that uses --config-user-dir= to specify the directory
instead. (For actual users of such symlinks, outisde of the test
suite, the directory is probably the same for both.)

This makes this feature work more like what the documentation
describes.

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

llvm-svn: 330871