[ObjC] Remove default parameter no caller was providing. NFC intended.

Currently there is no need to make ObjCTypeParamType have a canonical type
different from the one in corresponding ObjCTypeParamDecl. So remove the
corresponding unused API.

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

Release notes: Add the option WarnForDeadNestedAssignments
https://reviews.llvm.org/D66733

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

[Stats] Convert some ad-hoc header search stats to ALWAYS_ENABLED_STATISTIC.

rdar://problem/55715134

Reviewers: dsanders, bogner, rtereshin

Reviewed By: dsanders

Subscribers: hiraditya, jkorous, dexonsmith, ributzka, cfe-commits, llvm-commits

Tags: #llvm

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

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

Suppress false-positive -Wdeprecated-volatile warning from __is_*_assignable(volatile T&, U).

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

[clang][IFS] Fixing assert in clang interface stubs for enums, records, typedefs

The clang IFS ASTConsumer was asserting on enums, records (struct definitions in
C), and typedefs. All it needs to do is skip them because the stub just needs to
expose global object instances and functions.

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

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

Update clang module map for new excluded .def file.

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

Fix test failure with 374562 on Hexagon

__builtin_assume_aligned takes a size_t which is a 32 bit int on
hexagon.  Thus, the constant gets converted to a 32 bit value, resulting
in 0 not being a power of 2.  This patch changes the constant being
passed to 2**30 so that it fails, but doesnt exceed 30 bits.

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

Reland r374450 with Richard Smith's comments and test fixed.

The behavior from the original patch has changed, since we're no longer
allowing LLVM to just ignore the alignment.  Instead, we're just
assuming the maximum possible alignment.

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

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

[libTooling] Move `RewriteRule` abstraction into its own header and impl.

Summary: Move the `RewriteRule` class and related declarations into its own set
of files (header, implementation). Only the `Transformer` class is left in the
Transformer-named files. This change clarifies the distinction between the
`RewriteRule` class, which is essential to the Transformer library, and the
`Transformer` class, which is only one possible `RewriteRule` interpreter
(compare to `TransformerClangTidyCheck`, a clang-tidy based interpreter).

Reviewers: gribozavr

Subscribers: jfb, cfe-commits

Tags: #clang

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

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

[libTooling] Change Stencil equality to use `toString()`

Summary:
Removes the `isEqual` method from StencilPartInterface and modifies equality to
use the string representation returned by the `toString` method for comparison.

This means the `run` and `selection` stencils return true by default, and
clients should be cautious in relying on equality operator for comparison of
stencils containing parts generated by these functions.

It also means we no longer need the custom RTTI support (typeId() and
down_cast()), so it has been removed.

Patch by Harshal T. Lehri.

Reviewers: gribozavr

Subscribers: cfe-commits

Tags: #clang

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

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

[MS ABI]: Fix mangling function arguments for template types to be compatible with MSVC

MS name mangling supports cache for first 10 distinct function
arguments.  The error was when non cached template type occurred twice
(e.g. 11th and 12th).  For such case in code there is another cache
table TemplateArgStrings (for performance reasons).  Then one '@'
character at the end of the mangled name taken from this table was
missing.  For other cases the missing '@' character was added in
the call to mangleSourceName(TemplateMangling) in the cache miss code,
but the cache hit code didn't add it.

This fixes a regression from r362560.

Patch by Adam Folwarczny <adamf88@gmail.com>!

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

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

Dead Virtual Function Elimination

Currently, it is hard for the compiler to remove unused C++ virtual
functions, because they are all referenced from vtables, which are referenced
by constructors. This means that if the constructor is called from any live
code, then we keep every virtual function in the final link, even if there
are no call sites which can use it.

This patch allows unused virtual functions to be removed during LTO (and
regular compilation in limited circumstances) by using type metadata to match
virtual function call sites to the vtable slots they might load from. This
information can then be used in the global dead code elimination pass instead
of the references from vtables to virtual functions, to more accurately
determine which functions are reachable.

To make this transformation safe, I have changed clang's code-generation to
always load virtual function pointers using the llvm.type.checked.load
intrinsic, instead of regular load instructions. I originally tried writing
this using clang's existing code-generation, which uses the llvm.type.test
and llvm.assume intrinsics after doing a normal load. However, it is possible
for optimisations to obscure the relationship between the GEP, load and
llvm.type.test, causing GlobalDCE to fail to find virtual function call
sites.

The existing linkage and visibility types don't accurately describe the scope
in which a virtual call could be made which uses a given vtable. This is
wider than the visibility of the type itself, because a virtual function call
could be made using a more-visible base class. I've added a new
!vcall_visibility metadata type to represent this, described in
TypeMetadata.rst. The internalization pass and libLTO have been updated to
change this metadata when linking is performed.

This doesn't currently work with ThinLTO, because it needs to see every call
to llvm.type.checked.load in the linkage unit. It might be possible to
extend this optimisation to be able to use the ThinLTO summary, as was done
for devirtualization, but until then that combination is rejected in the
clang driver.

To test this, I've written a fuzzer which generates random C++ programs with
complex class inheritance graphs, and virtual functions called through object
and function pointers of different types. The programs are spread across
multiple translation units and DSOs to test the different visibility
restrictions.

I've also tried doing bootstrap builds of LLVM to test this. This isn't
ideal, because only classes in anonymous namespaces can be optimised with
-fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not
work correctly with -fvisibility=hidden. However, there are only 12 test
failures when building with -fvisibility=hidden (and an unmodified compiler),
and this change does not cause any new failures for either value of
-fvisibility.

On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size
reduction of ~6%, over a baseline compiled with "-O2 -flto
-fvisibility=hidden -fwhole-program-vtables". The best cases are reductions
of ~14% in 450.soplex and 483.xalancbmk, and there are no code size
increases.

I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which
show a geomean size reduction of ~3%, again with no size increases.

I had hoped that this would have no effect on performance, which would allow
it to awlays be enabled (when using -fwhole-program-vtables). However, the
changes in clang to use the llvm.type.checked.load intrinsic are causing ~1%
performance regression in the C++ parts of SPEC2006. It should be possible to
recover some of this perf loss by teaching optimisations about the
llvm.type.checked.load intrinsic, which would make it worth turning this on
by default (though it's still dependent on -fwhole-program-vtables).

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

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

Insert module constructors in a module pass

Summary:
If we insert them from function pass some analysis may be missing or invalid.
Fixes PR42877.

Reviewers: eugenis, leonardchan

Reviewed By: leonardchan

Subscribers: hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

llvm-svn: 374481
Signed-off-by: Vitaly Buka <vitalybuka@google.com>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@374527 91177308-0d34-0410-b5e6-96231b3b80d8

[X86] Always define the tzcnt intrinsics even when _MSC_VER is defined.

These intrinsics use llvm.cttz intrinsics so are always available
even without the bmi feature. We already don't check for the bmi
feature on the intrinsics themselves. But we were blocking the
include of the header file with _MSC_VER unless BMI was enabled
on the command line.

Fixes PR30506.

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

Revert 374481 "[tsan,msan] Insert module constructors in a module pass"

CodeGen/sanitizer-module-constructor.c fails on mac and windows, see e.g.
http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/11424

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

[CUDA][HIP} Add a test for constexpr default ctor

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

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

Fix assertion failure for a cv-qualified array as a non-type template
parameter type.

We were both failing to decay the array type to a pointer and failing to
remove the top-level cv-qualifications. Fix this by decaying array
parameters even if the parameter type is dependent.

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

Include whether the destructor is constexpr in -ast-dump output for a
clss.

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

Move most CXXRecordDecl::DefinitionData bit-fields out into a separate
file.

Reduces duplication and thereby reduces the risk that someone will
forget to update one of these places, as I did when adding
DefaultedDestructorIsConstexpr (though I've been unable to produce
a testcase for which that matters so far).

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

[tsan,msan] Insert module constructors in a module pass

Summary:
If we insert them from function pass some analysis may be missing or invalid.
Fixes PR42877.

Reviewers: eugenis, leonardchan

Reviewed By: leonardchan

Subscribers: hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

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

[tooling] Fix assertion on MacOSX.

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

[tooling] Teach Tooling to understand compilation with offloading.

Summary:
- So far, we only recognize the host compilation with offloading and
  skip the offloading part.

Reviewers: tra, yaxunl

Subscribers: cfe-commits

Tags: #clang

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

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

Fix help message for -ffp-contract

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

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

PR43629: Fix crash evaluating constexpr placement new on a subobject of
an out-of-lifetime object.

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

Fix some errors in <arm_neon.h> tests that cause them to fail with lax
vector conversions disabled.

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

Revert 374450 "Fix __builtin_assume_aligned with too large values."

The test fails on Windows, with

  error: 'warning' diagnostics expected but not seen:
    File builtin-assume-aligned.c Line 62: requested alignment
        must be 268435456 bytes or smaller; assumption ignored
  error: 'warning' diagnostics seen but not expected:
    File builtin-assume-aligned.c Line 62: requested alignment
        must be 8192 bytes or smaller; assumption ignored

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

Fix __builtin_assume_aligned with too large values.

Code to handle __builtin_assume_aligned was allowing larger values, but
would convert this to unsigned along the way. This patch removes the
EmitAssumeAligned overloads that take unsigned to do away with this
problem.

Additionally, it adds a warning that values greater than 1 <<29 are
ignored by LLVM.

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

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

Add -fgnuc-version= to control __GNUC__ and other GCC macros

I noticed that compiling on Windows with -fno-ms-compatibility had the
side effect of defining __GNUC__, along with __GNUG__, __GXX_RTTI__, and
a number of other macros for GCC compatibility. This is undesirable and
causes Chromium to do things like mix __attribute__ and __declspec,
which doesn't work. We should have a positive language option to enable
GCC compatibility features so that we can experiment with
-fno-ms-compatibility on Windows. This change adds -fgnuc-version= to be
that option.

My issue aside, users have, for a long time, reported that __GNUC__
doesn't match their expectations in one way or another. We have
encouraged users to migrate code away from this macro, but new code
continues to be written assuming a GCC-only environment. There's really
nothing we can do to stop that. By adding this flag, we can allow them
to choose their own adventure with __GNUC__.

This overlaps a bit with the "GNUMode" language option from -std=gnu*.
The gnu language mode tends to enable non-conforming behaviors that we'd
rather not enable by default, but the we want to set things like
__GXX_RTTI__ by default, so I've kept these separate.

Helps address PR42817

Reviewed By: hans, nickdesaulniers, MaskRay

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

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

[MSVC] Automatically add atlmfc folder to include and libpath.

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

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

[ScanDeps] clang-format, 80 cols.

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

[OPENMP]Update doc for supported constructs, NFC.

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

[OPENMP50]Support for 'master taskloop' directive.

Added full support for master taskloop directive.

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

[ARM] Fix arm_neon.h with -flax-vector-conversions=none, part 2.

Just running -fsyntax-only over arm_neon.h doesn't cover some intrinsics
which are defined using macros.  Add more test coverage for that.

arm-neon-header.c wasn't checking the full set of available NEON target
features; change the target architecture of the test to account for
that.

Fix the generator for arm_neon.h to generate casts in more cases where
they are necessary.

Fix VFMLAL_LOW etc. to express their signatures differently, so the
builtins have the expected type. Maybe the TableGen backend should
detect intrinsics that are defined the wrong way, and produce an error.
The rules here are sort of strange.

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

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

Fix one more clang test which didn't have \5C in it

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

Update clang tests for new LLVM IR backslash printing in r374415

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

Re-land "Use -fdebug-compilation-dir to form absolute paths in coverage mappings"

This reverts r374324 (git commit 62808631acceaa8b78f8ab9b407eb6b943ff5f77)

I changed the test to not rely on finding the sequence "clang, test,
CoverageMapping" in the CWD used to run the test. Instead it makes its
own internal directory hierarchy of foo/bar/baz and looks for that.

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

[clang-format] throws an incorrect assertion in consumeToken() formatting the MSVC stl

Summary:
An incorrect assertion is thrown when clang-formatting MSVC's STL library

```
Assertion failed: !Line.startsWith(tok::hash), file C:/llvm/llvm-project/clang/lib/Format/TokenAnnotator.cpp, line 847
Stack dump:
0.      Program arguments: C:\llvm\build\bin\clang-format.exe -i -n ./stl/inc/xkeycheck.h
```

```
Enable warning C4005 to find the forbidden define.
```

Reviewers: mitchell-stellar, STL_MSFT, klimek, krasimir

Reviewed By: mitchell-stellar

Subscribers: cfe-commits

Tags: #clang-format, #clang-tools-extra, #clang

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

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

[OPENMP50]Support for declare variant directive for NVPTX target.

NVPTX does not support global aliases. Instead, we have to copy the full
body of the variant function for the original function.

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

In openFileForRead don't cache erroneous entries if the error relates to them being directories. Add tests.

Summary:
It seems that when the CachingFileSystem is first given a file to open that is actually a directory, it incorrectly
caches that path to be errenous and throws an error when subsequently a directory open call is made for the same
path.
This change makes it so that we do NOT cache a path if it turns out we asked for a file when its a directory.

Reviewers: arphaman

Subscribers: dexonsmith, cfe-commits

Tags: #clang

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

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

[OPENMP50]Register vendor name only once in vendor context selector.

No need to store multiple copies of the same vendor names in the context
selector, keep only single copy.

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

Revert "[IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator"

This reverts commit r374240. It broke OCaml tests:
http://lab.llvm.org:8011/builders/clang-x86_64-debian-fast/builds/19014

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

[AST] ASTReader::ReadSLocEntry(): move computation of FirstDecl into the branch where it's used

The existing code is not defined, you are not allowed
to produce non-null pointer from null pointer (F->FileSortedDecls here).
That being said, i'm not really confident this is fix-enough, but we'll see.

FAIL: Clang :: Modules/no-module-map.cpp (6879 of 16079)
******************** TEST 'Clang :: Modules/no-module-map.cpp' FAILED ********************
Script:
--
: 'RUN: at line 1';   /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/lib/clang/10.0.0/include -nostdsysteminc -fmodules-ts -fmodule-name=ab -x c++-header /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/Inputs/no-module-map/a.h /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/Inputs/no-module-map/b.h -emit-header-module -o /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/clang/test/Modules/Output/no-module-map.cpp.tmp.pcm
: 'RUN: at line 2';   /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/lib/clang/10.0.0/include -nostdsysteminc -fmodules-ts -fmodule-file=/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/clang/test/Modules/Output/no-module-map.cpp.tmp.pcm /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/no-module-map.cpp -I/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/Inputs/no-module-map -verify
: 'RUN: at line 3';   /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/lib/clang/10.0.0/include -nostdsysteminc -fmodules-ts -fmodule-file=/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/clang/test/Modules/Output/no-module-map.cpp.tmp.pcm /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/no-module-map.cpp -I/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/Inputs/no-module-map -verify -DA
: 'RUN: at line 4';   /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/lib/clang/10.0.0/include -nostdsysteminc -fmodules-ts -fmodule-file=/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/clang/test/Modules/Output/no-module-map.cpp.tmp.pcm /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/no-module-map.cpp -I/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/Inputs/no-module-map -verify -DB
: 'RUN: at line 5';   /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/lib/clang/10.0.0/include -nostdsysteminc -fmodules-ts -fmodule-file=/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/clang/test/Modules/Output/no-module-map.cpp.tmp.pcm /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/no-module-map.cpp -I/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/Inputs/no-module-map -verify -DA -DB
: 'RUN: at line 7';   /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/lib/clang/10.0.0/include -nostdsysteminc -E /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/clang/test/Modules/Output/no-module-map.cpp.tmp.pcm -o - | /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/FileCheck /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/no-module-map.cpp
: 'RUN: at line 8';   /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang -cc1 -internal-isystem /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/lib/clang/10.0.0/include -nostdsysteminc -frewrite-imports -E /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/tools/clang/test/Modules/Output/no-module-map.cpp.tmp.pcm -o - | /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/FileCheck /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/test/Modules/no-module-map.cpp
--
Exit Code: 2

Command Output (stderr):
--
/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Serialization/ASTReader.cpp:1526:50: runtime error: applying non-zero offset 8 to null pointer
    #0 0x3a9bd0c in clang::ASTReader::ReadSLocEntry(int) /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Serialization/ASTReader.cpp:1526:50
    #1 0x328b6f8 in clang::SourceManager::loadSLocEntry(unsigned int, bool*) const /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Basic/SourceManager.cpp:461:28
    #2 0x328b351 in clang::SourceManager::initializeForReplay(clang::SourceManager const&) /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Basic/SourceManager.cpp:399:11
    #3 0x3996c71 in clang::FrontendAction::BeginSourceFile(clang::CompilerInstance&, clang::FrontendInputFile const&) /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Frontend/FrontendAction.cpp:581:27
    #4 0x394f341 in clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:956:13
    #5 0x3a8a92b in clang::ExecuteCompilerInvocation(clang::CompilerInstance*) /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:290:25
    #6 0xaf8d62 in cc1_main(llvm::ArrayRef<char const*>, char const*, void*) /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/tools/driver/cc1_main.cpp:250:15
    #7 0xaf1602 in ExecuteCC1Tool /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/tools/driver/driver.cpp:309:12
    #8 0xaf1602 in main /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/tools/driver/driver.cpp:382:12
    #9 0x7f2c1eecc2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
    #10 0xad57f9 in _start (/b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm_build_ubsan/bin/clang-10+0xad57f9)

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /b/sanitizer-x86_64-linux-bootstrap-ubsan/build/llvm-project/clang/lib/Serialization/ASTReader.cpp:1526:50 in

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

Revert "Use -fdebug-compilation-dir to form absolute paths in coverage mappings"

This reverts commit f6777964bde28c349d3e289ea37ecf5f5eeedbc4.

Because the absolute path check relies on temporary path containing
"clang", "test" and "CoverageMapping" as a subsequence, which is not
necessarily true on all systems(breaks internal integrates). Wanted to
fix it by checking for a leading "/" instead, but then noticed that it
would break windows tests, so leaving it to the author instead.

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

Remove rest of time-trace message as it is inconsistent style

Other options which create output files don't produce output messages.
Improve documentation to help find trace file.

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

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

[UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined behaviour

Summary:
Quote from http://eel.is/c++draft/expr.add#4:
```
4     When an expression J that has integral type is added to or subtracted
      from an expression P of pointer type, the result has the type of P.
(4.1) If P evaluates to a null pointer value and J evaluates to 0,
      the result is a null pointer value.
(4.2) Otherwise, if P points to an array element i of an array object x with n
      elements ([dcl.array]), the expressions P + J and J + P
      (where J has the value j) point to the (possibly-hypothetical) array
      element i+j of x if 0≤i+j≤n and the expression P - J points to the
      (possibly-hypothetical) array element i−j of x if 0≤i−j≤n.
(4.3) Otherwise, the behavior is undefined.
```

Therefore, as per the standard, applying non-zero offset to `nullptr`
(or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value
from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined,
i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.)

To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer
is undefined, although Clang front-end pessimizes the code by not lowering
that info, so this UB is "harmless".

Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`)
LLVM middle-end uses those guarantees for transformations.
If the source contains such UB's, said code may now be miscompiled.
Such miscompilations were already observed:
* https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html
* https://github.com/google/filament/pull/1566

Surprisingly, UBSan does not catch those issues
... until now. This diff teaches UBSan about these UB's.

`getelementpointer inbounds` is a pretty frequent instruction,
so this does have a measurable impact on performance;
I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%),
and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark:
(all measurements done with LLVM ToT, the sanitizer never fired.)
* no sanitization vs. existing check: average `+21.62%` slowdown
* existing check vs. check after this patch: average `22.04%` slowdown
* no sanitization vs. this patch: average `48.42%` slowdown

Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers

Reviewed By: rsmith

Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits

Tags: #clang, #sanitizers, #llvm

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

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

Recommit "[Clang] Pragma vectorize_width() implies vectorize(enable)"

This was further discussed at the llvm dev list:

http://lists.llvm.org/pipermail/llvm-dev/2019-October/135602.html

I think the brief summary of that is that this change is an improvement,
this is the behaviour that we expect and promise in ours docs, and also
as a result there are cases where we now emit diagnostics whereas before
pragmas were silently ignored. Two areas where we can improve: 1) the
diagnostic message itself, and 2) and in some cases (e.g. -Os and -Oz)
the vectoriser is (quite understandably) not triggering.

Original commit message:

Specifying the vectorization width was supposed to implicitly enable
vectorization, except that it wasn't really doing this. It was only
setting the vectorize.width metadata, but not vectorize.enable.

This should fix PR27643.

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

[clang] prevent crash for nonnull attribut in constant context (Bug 43601)

Summary:

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

Reviewers: rnk

Reviewed By: rnk

Subscribers: cfe-commits

Tags: #clang

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

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

[ast] Fix indentation. NFC.

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

[sema] Revise `getCurrentMangleNumberContext` interface. NFC.

- Prefer returning mulitple values using a tuple instead of
  additional pointers/references.

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

[libTooling] Move Transformer files to their own directory/library.

Summary:
The Transformer library has been growing inside of
lib/Tooling/Refactoring. However, it's not really related to anything else in
that directory. This revision moves all Transformer-related files into their own
include & lib directories.  A followup revision will (temporarily) add
forwarding headers to help any users migrate their code to the new location.

Reviewers: gribozavr

Subscribers: mgorny, cfe-commits

Tags: #clang

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

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

Re-land [mangle] Fix mangling where an extra mangle context is required.

This reverts r374268 (git commit c34385d07c7d59447bf836b740f032235391d121)

I think I reverted this by mistake, so I'm relanding it. While my bisect
found this revision, I think the crashes I'm seeing locally must be
environmental. Maybe the version of clang I'm using miscompiles tot
clang.

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

Revert [mangle] Fix mangling where an extra mangle context is required.

This reverts r374200 (git commit fd18e94697c987d5f24e25aa4e27adaffff3cce4)

Causes crashes just compiling `int main() {}` on my machine.

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

Use -fdebug-compilation-dir to form absolute paths in coverage mappings

This allows users to explicitly request relative paths with
`-fdebug-compilation-dir .`.

Fixes PR43614

Reviewers: vsk, arphaman

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

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

[CUDA][HIP] Fix host/device check with -fopenmp

CUDA/HIP program may be compiled with -fopenmp. In this case, -fopenmp is only passed to host compilation
to take advantages of multi-threads computation.

CUDA/HIP and OpenMP both use Sema::DeviceCallGraph to store functions to be analyzed and remove them
once they decide the function is sure to be emitted. CUDA/HIP and OpenMP have different functions to determine
if a function is sure to be emitted.

To check host/device correctly for CUDA/HIP when -fopenmp is enabled, there needs a unified logic to determine
whether a function is to be emitted. The logic needs to be aware of both CUDA and OpenMP logic.

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

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

[IRBuilder] Update IRBuilder::CreateFNeg(...) to return a UnaryOperator

Also update Clang to call Builder.CreateFNeg(...) for UnaryMinus.

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

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

[OPENMP50]Fix scoring of contexts with and without user provided scores.

The context selector with user provided score must have higher score
than the context selector without user provided score.

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

[Clang][OpenMP Offload] Add new tool for wrapping offload device binaries

This patch removes the remaining part of the OpenMP offload linker scripts which was used for inserting device binaries into the output linked binary. Device binaries are now inserted into the host binary with a help of the wrapper bit-code file which contains device binaries as data. Wrapper bit-code file is dynamically created by the clang driver with a help of new tool clang-offload-wrapper which takes device binaries as input and produces bit-code file with required contents. Wrapper bit-code is then compiled to an object and resulting object is appended to the host linking by the clang driver.

This is the second part of the patch for eliminating OpenMP linker script (please see https://reviews.llvm.org/D64943).

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

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

[ObjC generics] Fix not inheriting type bounds in categories/extensions.

When a category/extension doesn't repeat a type bound, corresponding
type parameter is substituted with `id` when used as a type argument. As
a result, in the added test case it was causing errors like

> type argument 'T' (aka 'id') does not satisfy the bound ('id<NSCopying>') of type parameter 'T'

We are already checking that type parameters should be consistent
everywhere (see `checkTypeParamListConsistency`) and update
`ObjCTypeParamDecl` to have correct underlying type. And when we use the
type parameter as a method return type or a method parameter type, it is
substituted to the bounded type. But when we use the type parameter as a
type argument, we check `ObjCTypeParamType` that ignores the updated
underlying type and remains `id`.

Fix by desugaring `ObjCTypeParamType` to the underlying type, the same
way we are doing with `TypedefType`.

rdar://problem/54329242

Reviewers: erik.pilkington, ahatanak

Reviewed By: erik.pilkington

Subscribers: jkorous, dexonsmith, ributzka, cfe-commits

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

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

[mangle] Fix mangling where an extra mangle context is required.

Summary:
- [Itanium C++ ABI][1], for certain contexts like default parameter and
  etc., mangling numbering will be local to the particular argument in
  which it appears.
- However, for these cases, the mangle numbering context is allocated per
  expression evaluation stack entry. That causes, for example, two
  lambdas defined/used understand the same default parameter are
  numbered as the same value and, in turn, one of them is not generated
  at all.
- In this patch, an extra mangle numbering context map is maintained in
  the AST context to map taht extra declaration context to its numbering
  context. So that, 2 different lambdas defined/used in the same default
  parameter are numbered differently.

[1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html

Reviewers: rsmith, eli.friedman

Subscribers: cfe-commits

Tags: #clang

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

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

[HIP] Fix -save-temps

Currently clang does not save some of the intermediate file generated during device compilation for HIP when -save-temps is specified.

This patch fixes that.

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

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

[ARM] Fix arm_neon.h with -flax-vector-conversions=none

Really, we were already 99% of the way there; just needed a couple minor
fixes that affected 64-bit-only builtins.  Based on D61717.

Note that the change to builtin_str changes the type of a few
__builtin_neon_* intrinsics that had the "wrong" type.

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

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

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

[WebAssembly] Add builtin and intrinsic for v8x16.swizzle

Summary:
This clang builtin and corresponding LLVM intrinsic are necessary to
expose the exact semantics of the underlying WebAssembly instruction
to users. LLVM produces a poison value if the dynamic swizzle indices
are greater than the vector size, but the WebAssembly instruction sets
the corresponding output lane to zero. Users who depend on this
behavior can safely use this builtin.

Depends on D68527.

Reviewers: aheejin, dschuff

Subscribers: sbc100, jgravelle-google, hiraditya, sunfish, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

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

[NFC] Reverting changes from test commit.
llvm commit access test succeeded.

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

[NFC] Test commit.
Testing llvm commit access only.

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

[clang-format] Update noexcept reference qualifiers detection

Summary:
r373165 fixed an issue where a templated noexcept member function with a
reference qualifier would be indented more than expected:
```
// Formatting produced with LLVM style with AlwaysBreakTemplateDeclarations: Yes

// before r373165:
struct f {
  template <class T>
      void bar() && noexcept {}
};

// after:
struct f {
  template <class T>
  void bar() && noexcept {}
};

```
The way this is done is that in the AnnotatingParser in
`lib/FormatTokenAnnotator.cpp` the determination of the usage of a `&` or `&&`
(the line in determineTokenType

```
Current.Type = determineStarAmpUsage(...
```
is not performed in some cases anymore, combining with a few additional related
checks afterwards. The net effect of these checks results in the `&` or `&&`
token to start being classified as `TT_Unknown` in cases where before `r373165`
it would be classified as `TT_UnaryOperator` or `TT_PointerOrReference` by
`determineStarAmpUsage`.

This inadvertently caused 2 classes of regressions I'm aware of:

- The address-of `&` after a function assignment would be classified as
  `TT_Unknown`, causing spaces to surround it, disregarding style options:
```
// before r373165:
void (*fun_ptr)(void) = &fun;

// after:
void (*fun_ptr)(void) = & fun;
```

- In cases where there is a function declaration list -- looking macro between
  a template line and the start of the function declaration, an `&` as part of
  the return type would be classified as `TT_Unknown`, causing spaces to
  surround it:
```
// before r373165:
template <class T>
DEPRECATED("lala")
Type& foo();

// after:
template <class T>
DEPRECATED("lala")
Type & foo();
```

In these cases the problems are rooted in the skipping of the classification of
a `&` (and similarly `&&`) by determineStarAmpUsage which effects the formatting
decisions later in the pipeline.

I've looked into the goal of r373165 and noticed that replacing `noexcept` with
`const` in the given example produces no extra indentation with the old code:
```
// before r373165:
struct f {
  template <class T>
  int foo() & const {}
};

struct f {
  template <class T>
      int foo() & noexcept {}
};
```

I investigated how clang-format annotated these two examples differently to
determine the places where the processing of both diverges in the pipeline.
There were two places where the processing diverges, causing the extra indent in
the `noexcept` case:
1. The `const` is annotated as a `TT_TrailingAnnotation`, whereas `noexcept`
   is annotated as `TT_Unknown`. I've updated the `determineTokenType` function
   to account for this by adding a missing `tok:kw_noexcept` to the clause that
   marks a token as `TT_TrailingAnnotation`.
2. The `&` in the second example is wrongly identified as `TT_BinaryOperator`
   in `determineStarAmpUsage`. This is the reason for the extra indentation --
   clang-format gets confused and thinks this is an expression.
   I've updated `determineStarAmpUsage` to check for `tok:kw_noexcept`.

With these two updates in place, the additional parsing introduced by r373165
becomes unnecessary and all added tests pass (with updates, as now clang-format
respects the style configuration for spaces around the `&` in the test
examples).
I've removed these additions and added regression tests for the cases above.

Reviewers: AndWass, MyDeveloperDay

Reviewed By: MyDeveloperDay

Subscribers: cfe-commits

Tags: #clang, #clang-format

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

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

[clang-offload-bundler] Support `.cui` and `.d`.

Reviewers: tra, yaxunl

Subscribers: cfe-commits

Tags: #clang

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

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

[mips] Set default float ABI to "soft" on FreeBSD

Initial patch by Kyle Evans.

Fix PR43596

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

[DebugInfo] Enable call site debug info for ARM and AArch64

ARM and AArch64 SelectionDAG support for tacking parameter forwarding
register is implemented so we can allow clang invocations for those two
targets.
Beside that restrict debug entry value support to be emitted for
LimitedDebugInfo info and FullDebugInfo. Other types of debug info do
not have functions nor variables debug info.

Reviewers: aprantl, probinson, dstenb, vsk

Reviewed By: vsk

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

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

[Sema] Emit diagnostics for uncorrected delayed typos at the end of TU

Summary:
Instead of asserting all typos are corrected in the sema destructor.

The sema destructor is not run in the common case of running the compiler
with the -disable-free cc1 flag (which is the default in the driver).

Having this assertion led to crashes in libclang and clangd, which are not
reproducible when running the compiler.

Asserting at the end of the TU could be an option, but finding all
missing typo correction cases is hard and having worse diagnostics instead
of a failing assertion is a better trade-off.

For more discussion on this, see:
https://lists.llvm.org/pipermail/cfe-dev/2019-July/062872.html

Reviewers: sammccall, rsmith

Reviewed By: rsmith

Subscribers: usaxena95, dgoldman, jkorous, vsapsai, rnk, kadircet, cfe-commits

Tags: #clang

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

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

Revert r374006: Reland 'Add VFS support for sanitizers' blacklist'

Also revert follow-up changes to the test.
Reason: the patch breaks our internal clang-tidy integration.

It's also unclear why we should use getRealPath instead of plumbing the
VFS to SanitizerBlacklist, see original commit thread of cfe-commits for
a discussion.

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

Unify the two CRC implementations

David added the JamCRC implementation in r246590. More recently, Eugene
added a CRC-32 implementation in r357901, which falls back to zlib's
crc32 function if present.

These checksums are essentially the same, so having multiple
implementations seems unnecessary. This replaces the CRC-32
implementation with the simpler one from JamCRC, and implements the
JamCRC interface in terms of CRC-32 since this means it can use zlib's
implementation when available, saving a few bytes and potentially making
it faster.

JamCRC took an ArrayRef<char> argument, and CRC-32 took a StringRef.
This patch changes it to ArrayRef<uint8_t> which I think is the best
choice, and simplifies a few of the callers nicely.

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

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

[c++20] P1152R4: warn on any simple-assignment to a volatile lvalue
whose value is not ignored.

We don't warn on all the cases that are deprecated: specifically, we
choose to not warn for now if there are parentheses around the
assignment but its value is not actually used. This seems like a more
defensible rule, particularly for cases like sizeof(v = a), where the
parens are part of the operand rather than the sizeof syntax.

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

[c++20] Implement most of P1152R4.

Diagnose some now-deprecated uses of volatile types:
 * as function parameter types and return types
 * as the type of a structured binding declaration
 * as the type of the lvalue operand of an increment / decrement /
   compound assignment operator

This does not implement a check for the deprecation of simple
assignments whose results are used; that check requires somewhat
more complexity and will be addressed separately.

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

[cxx_status] Note that Clang has supported std::source_location since
version 9.

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

Factor out some duplication. NFC.

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

[clang-scan-deps] Improve string/character literal skipping

The existing string/character literal skipping code in the
dependency directives source minimizer has two issues:

- It doesn't stop the scanning when a newline is reached before the terminating character,
unlike the lexer which considers the token to be done (even if it's invalid) at the end of the line.

- It doesn't support whitespace between '\' and the newline when looking if the '\' is used as a line continuation character.

This commit fixes both issues.

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

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

[IRGen] Emit lifetime markers for temporary struct allocas

When passing arguments using temporary allocas, we need to add the
appropriate lifetime markers so that the stack coloring passes can
re-use the stack space.

This patch keeps track of all the lifetime.start calls emited before the
codegened call, and adds the corresponding lifetime.end calls after the
call.

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

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

Fix crash or wrong code bug if a lifetime-extended temporary contains a
"non-constant" value.

If the constant evaluator evaluates part of a variable initializer,
including the initializer for some lifetime-extended temporary, but
fails to fully evaluate the initializer, it can leave behind wrong
values for temporaries encountered in that initialization. Don't try to
emit those from CodeGen! Instead, look at the values that constant
evaluation produced if (and only if) it actually succeeds and we're
emitting the lifetime-extending declaration's initializer as a constant.

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

[clang] enable_trivial_var_init_zero should not be Joined<>

Reviewers: rnk

Subscribers: cfe-commits

Tags: #clang

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

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

[clang] Add llvm-ifs in test deps

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

[OPENMP50]Multiple vendors in vendor context must be treated as logical
and of vendors, not or.

If several vendors are provided in the same vendor context trait, the
context shall match only if all vendors are matching, not one of them.
This is per OpenMP 5.0, 2.3.3 Matching and Scoring Context Selectors,
all selectors in the construct, device, and implementation sets of the
context selector appear in the corresponding trait set of the OpenMP
context.

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

Try to get ubsan-blacklist-vfs.c pass more on Windows

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

[BPF] do compile-once run-everywhere relocation for bitfields

A bpf specific clang intrinsic is introduced:
   u32 __builtin_preserve_field_info(member_access, info_kind)
Depending on info_kind, different information will
be returned to the program. A relocation is also
recorded for this builtin so that bpf loader can
patch the instruction on the target host.
This clang intrinsic is used to get certain information
to facilitate struct/union member relocations.

The offset relocation is extended by 4 bytes to
include relocation kind.
Currently supported relocation kinds are
 enum {
    FIELD_BYTE_OFFSET = 0,
    FIELD_BYTE_SIZE,
    FIELD_EXISTENCE,
    FIELD_SIGNEDNESS,
    FIELD_LSHIFT_U64,
    FIELD_RSHIFT_U64,
 };
for __builtin_preserve_field_info. The old
access offset relocation is covered by
    FIELD_BYTE_OFFSET = 0.

An example:
struct s {
    int a;
    int b1:9;
    int b2:4;
};
enum {
    FIELD_BYTE_OFFSET = 0,
    FIELD_BYTE_SIZE,
    FIELD_EXISTENCE,
    FIELD_SIGNEDNESS,
    FIELD_LSHIFT_U64,
    FIELD_RSHIFT_U64,
};

void bpf_probe_read(void *, unsigned, const void *);
int field_read(struct s *arg) {
  unsigned long long ull = 0;
  unsigned offset = __builtin_preserve_field_info(arg->b2, FIELD_BYTE_OFFSET);
  unsigned size = __builtin_preserve_field_info(arg->b2, FIELD_BYTE_SIZE);
 #ifdef USE_PROBE_READ
  bpf_probe_read(&ull, size, (const void *)arg + offset);
  unsigned lshift = __builtin_preserve_field_info(arg->b2, FIELD_LSHIFT_U64);
 #if __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
  lshift = lshift + (size << 3) - 64;
 #endif
 #else
  switch(size) {
  case 1:
    ull = *(unsigned char *)((void *)arg + offset); break;
  case 2:
    ull = *(unsigned short *)((void *)arg + offset); break;
  case 4:
    ull = *(unsigned int *)((void *)arg + offset); break;
  case 8:
    ull = *(unsigned long long *)((void *)arg + offset); break;
  }
  unsigned lshift = __builtin_preserve_field_info(arg->b2, FIELD_LSHIFT_U64);
 #endif
  ull <<= lshift;
  if (__builtin_preserve_field_info(arg->b2, FIELD_SIGNEDNESS))
    return (long long)ull >> __builtin_preserve_field_info(arg->b2, FIELD_RSHIFT_U64);
  return ull >> __builtin_preserve_field_info(arg->b2, FIELD_RSHIFT_U64);
}

There is a minor overhead for bpf_probe_read() on big endian.

The code and relocation generated for field_read where bpf_probe_read() is
used to access argument data on little endian mode:
        r3 = r1
        r1 = 0
        r1 = 4  <=== relocation (FIELD_BYTE_OFFSET)
        r3 += r1
        r1 = r10
        r1 += -8
        r2 = 4  <=== relocation (FIELD_BYTE_SIZE)
        call bpf_probe_read
        r2 = 51 <=== relocation (FIELD_LSHIFT_U64)
        r1 = *(u64 *)(r10 - 8)
        r1 <<= r2
        r2 = 60 <=== relocation (FIELD_RSHIFT_U64)
        r0 = r1
        r0 >>= r2
        r3 = 1  <=== relocation (FIELD_SIGNEDNESS)
        if r3 == 0 goto LBB0_2
        r1 s>>= r2
        r0 = r1
LBB0_2:
        exit

Compare to the above code between relocations FIELD_LSHIFT_U64 and
FIELD_LSHIFT_U64, the code with big endian mode has four more
instructions.
        r1 = 41   <=== relocation (FIELD_LSHIFT_U64)
        r6 += r1
        r6 += -64
        r6 <<= 32
        r6 >>= 32
        r1 = *(u64 *)(r10 - 8)
        r1 <<= r6
        r2 = 60   <=== relocation (FIELD_RSHIFT_U64)

The code and relocation generated when using direct load.
        r2 = 0
        r3 = 4
        r4 = 4
        if r4 s> 3 goto LBB0_3
        if r4 == 1 goto LBB0_5
        if r4 == 2 goto LBB0_6
        goto LBB0_9
LBB0_6:                                 # %sw.bb1
        r1 += r3
        r2 = *(u16 *)(r1 + 0)
        goto LBB0_9
LBB0_3:                                 # %entry
        if r4 == 4 goto LBB0_7
        if r4 == 8 goto LBB0_8
        goto LBB0_9
LBB0_8:                                 # %sw.bb9
        r1 += r3
        r2 = *(u64 *)(r1 + 0)
        goto LBB0_9
LBB0_5:                                 # %sw.bb
        r1 += r3
        r2 = *(u8 *)(r1 + 0)
        goto LBB0_9
LBB0_7:                                 # %sw.bb5
        r1 += r3
        r2 = *(u32 *)(r1 + 0)
LBB0_9:                                 # %sw.epilog
        r1 = 51
        r2 <<= r1
        r1 = 60
        r0 = r2
        r0 >>= r1
        r3 = 1
        if r3 == 0 goto LBB0_11
        r2 s>>= r1
        r0 = r2
LBB0_11:                                # %sw.epilog
        exit

Considering verifier is able to do limited constant
propogation following branches. The following is the
code actually traversed.
        r2 = 0
        r3 = 4   <=== relocation
        r4 = 4   <=== relocation
        if r4 s> 3 goto LBB0_3
LBB0_3:                                 # %entry
        if r4 == 4 goto LBB0_7
LBB0_7:                                 # %sw.bb5
        r1 += r3
        r2 = *(u32 *)(r1 + 0)
LBB0_9:                                 # %sw.epilog
        r1 = 51   <=== relocation
        r2 <<= r1
        r1 = 60   <=== relocation
        r0 = r2
        r0 >>= r1
        r3 = 1
        if r3 == 0 goto LBB0_11
        r2 s>>= r1
        r0 = r2
LBB0_11:                                # %sw.epilog
        exit

For native load case, the load size is calculated to be the
same as the size of load width LLVM otherwise used to load
the value which is then used to extract the bitfield value.

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

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

[NFC] Attempt to make ubsan-blacklist-vfs test pass on Windows

Previously disabled in d0c2d5daa3e

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

[driver][hip] Skip bundler if host action is nothing.

Reviewers: sfantao, tra, yaxunl

Subscribers: cfe-commits

Tags: #clang

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

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

[OPENMP50]Do not allow multiple same context traits in the same context
selector.

According to OpenMP 5.0, 2.3.2 Context Selectors, Restrictions, each
trait-selector-name can only be specified once. Added check for this
restriction.

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

[OPENMP50]Prohibit multiple context selector sets in context selectors.

According to OpenMP 5.0, 2.3.2 Context Selectors, Restrictions, each
trait-set-selector-name can only be specified once. Added check to
implement this restriction.

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

[clang][ifs] Clang Interface Stubs ToolChain plumbing.

Second Landing Attempt:

This patch enables end to end support for generating ELF interface stubs
directly from clang. Now the following:

clang -emit-interface-stubs -o libfoo.so a.cpp b.cpp c.cpp

will product an ELF binary with visible symbols populated. Visibility attributes
and -fvisibility can be used to control what gets populated.

* Adding ToolChain support for clang Driver IFS Merge Phase
* Implementing a default InterfaceStubs Merge clang Tool, used by ToolChain
* Adds support for the clang Driver to involve llvm-ifs on ifs files.
* Adds -emit-merged-ifs flag, to tell llvm-ifs to emit a merged ifs text file
  instead of the final object format (normally ELF)

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

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

[OPENMP50]Allow functions in declare variant directive to have different
C linkage.

After some discussion with OpenMP developers, it was decided that the
functions with the different C linkage can be used in declare variant
directive.

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

[SVE][IR] Scalable Vector size queries and IR instruction support

* Adds a TypeSize struct to represent the known minimum size of a type
  along with a flag to indicate that the runtime size is a integer multiple
  of that size
* Converts existing size query functions from Type.h and DataLayout.h to
  return a TypeSize result
* Adds convenience methods (including a transparent conversion operator
  to uint64_t) so that most existing code 'just works' as if the return
  values were still scalars.
* Uses the new size queries along with ElementCount to ensure that all
  supported instructions used with scalable vectors can be constructed
  in IR.

Reviewers: hfinkel, lattner, rkruppe, greened, rovka, rengolin, sdesmalen

Reviewed By: rovka, sdesmalen

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

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

[Diagnostics] Silence -Wsizeof-array-div for character buffers

Summary:
Character buffers are sometimes used to represent a pool of memory that
contains non-character objects, due to them being synonymous with a stream of
bytes on almost all modern architectures. Often, when interacting with hardware
devices, byte buffers are therefore used as an intermediary and so we can end
Character buffers are sometimes used to represent a pool of memory that
contains non-character objects, due to them being synonymous with a stream of
bytes on almost all modern architectures. Often, when interacting with hardware
devices, byte buffers are therefore used as an intermediary and so we can end
up generating lots of false-positives.

Moreover, due to the ability of character pointers to alias non-character
pointers, the strict aliasing violations that would generally be implied by the
calculations caught by the warning (if the calculation itself is in fact
correct) do not apply here, and so although the length calculation may be
wrong, that is the only possible issue.

Reviewers: rsmith, xbolva00, thakis

Reviewed By: xbolva00, thakis

Subscribers: thakis, lebedev.ri, cfe-commits

Tags: #clang

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

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

Remove an useless allocation (from by clang-analyzer/scan-build)
https://llvm.org/reports/scan-build/report-TargetInfo.cpp-detectFPCCEligibleStruct-9-1.html#EndPath

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

[ItaniumMangle] Fix mangling of GNU __null in an expression to match GCC

Reviewers: rsmith

Reviewed By: rsmith

Subscribers: erik.pilkington, cfe-commits

Tags: #clang

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

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

[NFC] Fix ubsan-blacklist test

Restored original test and marked tests for VFS as unsupported on Windows.

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

Reland 'Add VFS support for sanitizers' blacklist'

The original patch broke the test for Windows.
Trying to fix as per Reid's suggestions outlined here:
https://reviews.llvm.org/rC371663

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

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

Revert "Add VFS support for sanitizers' blacklist"

Fix tests on Windows for now.

This reverts commit 96ac97a4213287003f08636d0c372b3f71e9cfca.

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

[clang] Accept -ftrivial-auto-var-init in clang-cl

Reviewers: eugenis, rnk

Subscribers: cfe-commits

Tags: #clang

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

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

Add VFS support for sanitizers' blacklist

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

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

[Diagnostics] Emit better -Wbool-operation's warning message if we known that the result is always true

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

[OPENMP]Fix caonical->canonical, NFC.

Fixed typo.

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