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

[NFC][CLANG] Fix Static Code Analyzer Concerns with dereference null return value in applyObjCTypeArgs()

This patch uses castAs instead of getAs to resolve dereference issue with nullptr boundObjC when calling
canAssignObjCInterfaces() or isObjCIdType() in applyObjCTypeArgs() since getAs returns nullptr.

Reviewed By: erichkeane

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

This patch uses castAs instead of getAs which will assert if the type doesn't match in clang::CodeGen::CodeGenTypes::GetFunctionTypeForVTable(clang::GlobalDecl).

Reviewed By: erichkeane

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

For the most part we already had the classes split and instantiated
in a way that the type is always the same for all instantiations of
the class.

Previously we checked isCLZForZeroUndef and only added UBSan checks
if it returned true.

The builtin should be considered undefined for 0 regardless of
the target so that code using it is portable. The isCLZForZeroUndef
was only intended to disable optimizations in the middle end and
backend.

See https://discourse.llvm.org/t/should-ubsan-detect-0-input-to-builtin-clz-ctz-regardless-of-target/71060

Reviewed By: nikic

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

KCFI traps should always be recoverable, but as Intrinsic::trap
is marked noreturn, it's not possible to continue execution after
handling the trap as the compiler is free to assume we never
return. Switch to debugtrap instead to ensure we have the option
to resume execution after the trap.

Currently symbols are not resolved for declare target
after they've been modified by prior passes. This can
lead to missing or incorrect symbols in subsequent
compiler phases when declare target is used with
more complex types e.g. common block.

This patch should allow these symbols to be
resolved appropriately.

Reviewers: kiranchandramohan

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

The C standard asserts that the `errno` value is an l-value thread local
integer. We cannot provide a generic thread local integer on the GPU
currently without some workarounds. Previously, we worked around this by
implementing the `errno` value as a special consumer class that made all
the writes disappear. However, this is problematic for internal tests.
Currently there are build failures because of this handling and it's
only likely to cause more problems the more we do this.

This patch instead makes the internal target used for testing export the
`errno` value as a simple global integer. This allows us to use and test
the `errno` interface correctly assuming we run with a single thread.
Because this is only used for the non-exported target we still do not
provide this feature in the version that users will use so we do not
need to worrk about it being incorrect in general.

Reviewed By: lntue

Differential Revision: https://reviews.ll...

Remove 'string vw' template parameter from classes where it always
has a one value.

For the 2 classes that need it, make it required instead of having a
default.

Summary:
Recently, the changes in https://reviews.llvm.org/D148793 introduced
some extra dependencies that caused link failured on my machine. This
patch adds the necessary libraries to resolve the link failures and
allow me to build again.

Revert rG2f9a4d30 "[GlobalISel][X86] Add G_CTLZ_ZERO_UNDEF legalization handling"

Unintentional commit - G_CTLZ_ZERO_UNDEF will have to be custom handled as BSR needs the bits flipping (and we don't have a pattern for that yet).

[bazel] Add include-cleaner targets, fix clang-tidy build for c28506ba

Reviewed By: aartbik

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

This test is redundant since we already test the same thing in our
nasty_macros test.

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

In addition to reducing the amount of boilerplate we need to generate
whenever a new header is added, this also improves the existing tests
by running them in separate Lit tests (so they can be parallelized).
This also creates separate translation units for most header tests,
which is what we really should have done from the start since it
isolates each header we're testing.

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

This patch adds the DFP compare instructions:
dcmpu, dcmpuq, dcmpo, dcmpoq

Reviewed By: amyk

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

With only a link action, we claim all CompileOnly_Group options (including -f*,
-m*, -i*, etc). It makes sense to claim -nostdinc family options as well.
We can achieve this by placing these options into IncludePath_Group, a derivative of
CompileOnly_Group.

Reviewed By: theuni

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

To define custom allocation, you only need to put the configuration in
custom_scudo_config.h and define two required aliases, then you will be
switched to the customized config and the tests will also run with your
configuration.

In this CL, we also have a minor refactor the structure of
configuration. Now the essential fields are put under the associated
hierarchy and which will make the defining new configuration easier.

Reviewed By: cferris

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

Without this patch, the following example crashes Clang:

```
 #pragma omp target map(i)
 #pragma omp tile sizes(2)
 for (i = 0; i < N; ++i)
   ;
```

This patch fixes the crash by changing `Sema::isOpenMPPrivateDecl` not
to identify `i` as private just because it's the loop variable of a
`tile` construct.

While OpenMP TR11 and earlier do specify privacy for loop variables of
loops *generated* from a `tile` construct, I haven't found text
stating that the original loop variable must be private in the above
example, so this patch leaves it shared.  Even so, it is a bit
unexpected that value of `i` after the loop is `N - 1` instead of `N`.

Reviewed By: ABataev

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

This patch makes sure that scalable indices (that would normally
represent scalable tile or vector sizes) are printed correctly, i.e.
with additional square brackets:
```
%1, %loop = transform.structured.tile %0 [2, 8, [4]]
```

This change complements https://reviews.llvm.org/D150944 and is a part
of a larger effort to enable scalable vectorisation in Linalg. See this
RFC for more context:
  * https://discourse.llvm.org/t/rfc-scalable-vectorisation-in-linalg/

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

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

Clang was rejecting valid code where GNU style attributes preceded C++ style
attributes in template declarations as follows:

template<int a>
__attribute__((deprecated("oh no!"))) [[deprecated("oh no!")]] void foo();

This PR fixes the bug.

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

[GlobalIsel][X86] Move G_SHL/G_LSHR/G_ASHR legalization before legacy handling and merge 32-bit/64-bit handling

[GlobalIsel][X86] Move G_SDIV/G_SREM/G_UDIV/G_UREM legalization before legacy handling and merge 32-bit/64-bit handling

Per 15.5.2.5 p2, when both a dummy data object and its associated
actual argument are ALLOCATABLE or POINTER, there are rules requiring
that both be unlimited polymorphic if either is, and that both be
polymorphic if either is.  The justifications for the first restriction
is that the called procedure might change the type of an unlimited
polymorphic dummy argument, but as this cannot occur for a dummy
argument with INTENT(IN), we can relax the check to an optional
portability warning.  The justification for the second restriction
is that some implementations would have to create a type descriptor
to associate a monomorphic allocatable/pointer actual argument with
a polymorphic dummy argument, and that doesn't apply to f18 since we
use descriptors for them anyways.

Relaxing these needless checks allows more library procedures to
use "class(*), dimension(..), pointer, intent(in)" dummy arguments
in explicit interfaces.

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

Reviewed By: HazardyKnusperkeks, MyDeveloperDay

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

This reverts commit fc011a72.
This reverts commit 4ad6a0c9.
This reverts commit 4b1eb4cf.

Still causes Windows build bots to fail.

The tests already depend on libc through various dependencies. In
addition, including C++STL inline functions may lead to ODR violations
where one version uses sanitizer_common's internal_mem*() functions, and
the other the normal memintrinsics.

Originally from the MVE tests, this adds tests for various operations which can
often be converted to predicated instructions under SVE. Additionally some tests
for commutativity and extra uses of the existing smin/smax operations. See the
patches D149969/ D151084 / D151080 / D149967 / etc.