FixIt, and add support for initialization check of scoped enum

In C++, the enumeration is never Integer, and the enumeration condition judgment is added to avoid compiling errors when it is initialized to an integer.
Add support for initialization check of scope enum.

As the following case show, clang-tidy will give a wrong automatic fix:

    enum Color {Red, Green, Blue};
    enum class Gender {Male, Female};
    void func() {
      Color color; // Color color = 0; <--- fix bug
      Gender gender; // <--- no warning
    }

Reviewd By: aaron.ballman, whisperity

Differential Revision: http://reviews.llvm.org/D106431

Port external-io test to use GTest. Remove Runtime tests directory.
Rename RuntimeGTest directory to Runtime.

This is the last in a series of patches which ported tests from the old
flang/unittests/Runtime test directory to use GTest in a temporary
unittest directory under flang/unittests/RuntimeGTest. Now that all the
tests in the old directory have been ported to use GTest, the old
directory has been removed and the GTest directory has been renamed to
flang/unittests/Runtime.

Differential Revision: https://reviews.llvm.org/D105315
Reviewed by: Meinersbur, awarzynski

The effect name is used by tablegen when generating the getEffects method of the SideEffectInterfaces. It is currently unqualified even though the class is contained within the mlir namespace, leading to compiler errors when using namespace mlir; isn't used before including the generated cpp file.

This patch fixes that by simply fully qualifying the class name.

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

Buildbot failure:
https://lab.llvm.org/buildbot/#/builders/105/builds/13141
which provides no details about why it failed, but the only failure
reports are for ppc64 bots.

The function seems to be unused for at least one year.

This patch will re-enable the patch posted under https://reviews.llvm.org/D106688 originally which was reverted due to buildbreak that was caused by mismatched diagnostic message arguments.

Reviewed By: Zarko Todorovski

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

All `nowait` series of interfaces in `libomptarget` accept four more arguments (`int32_t depNum, void *depList, int32_t noAliasDepNum, void *noAliasDepList`) compared with their counterparts w/o `nowait`. These extra arguments were expected for dependence resolution, potentially lowered to device side. Current implementation calls `libomp` function `__kmpc_omp_taskwait`. However, the front end simply ignores them, that these four arguments are not emitted at all. As a consequence, the `depNum` and `noAliasDepNum` are garbage, which could lead to unnecessary task wait.

Reviewed By: grokos

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

Reviewed By: GMNGeoffrey

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

We currently handle scalar but not vector cases

Buildbot failure:
https://lab.llvm.org/buildbot/#/builders/105/builds/13139
which provides no details about why it failed.

'pipe' keyword is introduced in OpenCL C 2.0: so do checks for OpenCL C version while
parsing and then later on check for language options to construct actual pipe. This feature
requires support of __opencl_c_generic_address_space, so diagnostics for that is provided as well.

This is the same patch as in D106748 but with a tiny fix in checking of diagnostic messages.
Also added tests when program scope global variables are not supported.

Reviewed By: Anastasia

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

Reviewed By: efriedma

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

Commit 83df1220 (r368334) added 'REQUIRES: linux' to this test, but
because triples are not respected by REQUIRES, that meant it was
invariably Unsupported.  The correct keyword would be 'system-linux'
(checking the host rather than the target).

Because the test was always skipped, commit 0cfd9e5b (r375439) did not
notice that the test modification was incorrect.

This patch corrects the REQUIRES clause and fixes the incorrect
previous patch.

Found after implementing https://reviews.llvm.org/D107162

With this patch, OpenMP on AMDGCN will use the math functions
provided by ROCm ocml library. Linking device code to the ocml will be
done in the next patch.

Reviewed By: JonChesterfield, jdoerfert, scchan

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

Under the -faltivec-src-compat=gcc option, AltiVec vector initialization should
be treated as if they were compiled with gcc - which is, to emit an error when
the vectors are initialized in the parenthesized or non-parenthesized manner.
This patch implements this behaviour.

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

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

Put declarations/definitions of unused variables under corresponding macros
to silence clang build warnings.

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

In a post-commit message to https://reviews.llvm.org/D102343
@MaskRay pointed out syntax errors in one of the test cases. This
patch fixes those problems, I had forgotten the colon after the CHECK- strings.

Math libraries are linked only when -lm is specified. This is because
host system could be missing rocm-device-libs.

Reviewed By: JonChesterfield, yaxunl

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

This adds a combine for adds of reductions, distributing them so that
they occur sequentially to enable better use of accumulating VADDVA
instructions. It combines:
  add(X, add(vecreduce(Y), vecreduce(Z))) ->
    add(add(X, vecreduce(Y)), vecreduce(Z))
and
  add(add(A, reduce(B)), add(C, reduce(D))) ->
    add(add(add(A, C), reduce(B)), reduce(D))

These together distribute the add's so that more reductions can be
selected to VADDVA.

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

This patch should fix the build we observe when building LLVM from scratch.

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

Also, improve tests for std::destroy and std::destroy_n so that they
check for array support.

These changes are part of http://wg21.link/p0896 (the One Ranges proposal).

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

This is a gauage metric that sets particular remote-index instances as
used. It should enable accumulation of multiple streams to see number of clangd
processes making use of remote index, broken down by remote index address.

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

Background-indexing is fine, because it uses GlobalCompilationDatabase
to fetch the compile commands (hence uses CommandMangler), and creates
invocation through buildCompilerInvocation.

Depends on D106639.

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

It is not great to list diag ids by hand, but I don't see any other
solution unless diagnostics are annotated with these explicitly, which is a
bigger change in clang and I am not sure if would be worth it.

Diagnostics handled by this patch is by no means exhaustive, there might be
other checks that don't mention "unused"/"deprecated" in their names. But it
feels like this should be enough to catch common diagnostics and can be extended
over time.

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

Reviewed By: vitalybuka

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

This reverts commit e7b8ba10.

It broke 32-bit ARM - lldb-arm-ubuntu, reported by omjavaid:
  https://lab.llvm.org/buildbot/#/builders/17/builds/9595

For the nodes with reused scalars the user may be not only of the size
of the final shuffle but also of the size of the scalars themselves,
need to check for this. It is safe to just modify the check here, since
the order of the scalars themselves is preserved, only indeces of the
reused scalars are changed. So, the users with the same size as the
number of scalars in the node, will not be affected, they still will get
the operands in the required order.

Reported by @mstorsjo in D105020.

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

If the instruction was previously deleted, it should not be treated as
an external user. This fixes cost estimation and removes dead
extractelement instructions.

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

See https://github.com/clangd/clangd/issues/649#issuecomment-885903316.
Also disables config support in lit tests to make sure tests are not affected by
clangd config files lying around.

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

Need to check that the minimum acceptable vector factor is at least 2,
not 0, to avoid compiler crash during gathered loads analysis.

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

This introduces a builder function for emitting IR performing reductions in
OpenMP. Reduction variable privatization and initialization to the
reduction-neutral value is expected to be handled separately. The caller
provides the reduction functions. Further commits can provide implementation of
reduction functions for the reduction operators defined in the OpenMP
specification.

This implementation was tested on an MLIR fork targeting OpenMP from C and
produced correct executable code.

Reviewed By: Meinersbur

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

This change makes sure that DwarfUnit does not load a .dwo file until
necessary. I also take advantage of DWARF 5's guarantee that the first
support file is also the primary file to make it possible to create
a compile unit without loading the .dwo file.

Review By: jankratochvil, dblaikie

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

The test contains a race in memset.
The size of reported race depends on how the accessed
memory range split into granules inside of tsan runtime.
The test used to report access of size 8, because presumably
the buffer ended up being aligned to 8 bytes. But after
some unrelated changes this test started to report accesses
of size 1 (presumably .data layout changed), which makes
the test fail.
Guarantee alignment of the buf object explicitly.

Reviewed By: melver

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

Make New<>() a variadic function template and forward any arguments to
the constructor. std::forward<>() is inlined to avoid including
<utility>.

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

The "memory tag read" command will now tell you
when the allocation tag read does not match the logical
tag.

(lldb) memory tag read mte_buf+(8*16) mte_buf+(8*16)+48
Logical tag: 0x9
Allocation tags:
[0xfffff7ff7080, 0xfffff7ff7090): 0x8 (mismatch)
[0xfffff7ff7090, 0xfffff7ff70a0): 0x9
[0xfffff7ff70a0, 0xfffff7ff70b0): 0xa (mismatch)

The logical tag will be taken from the start address
so the end could have a different tag. You could for example
read from ptr_to_array_1 to ptr_to_array_2. Where the latter
is tagged differently to prevent buffer overflow.

The existing command will read 1 granule if you leave
off the end address. So you can also use it as a quick way
to check a single location.

(lldb) memory tag read mte_buf
Logical tag: 0x9
Allocation tags:
[0xfffff7ff7000, 0xfffff7ff7010): 0x0 (mismatch)

This avoids the need for a seperate "memory tag check" command.

Reviewed By: omjavaid

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

The type field is a signed integer.
(https://sourceware.org/gdb/current/onlinedocs/gdb/General-Query-Packets.html)

However it's not packed in the packet in the way
you might think. For example the type -1 should be:
qMemTags:<addr>,<len>:ffffffff
Instead of:
qMemTags:<addr>,<len>:-1

This change makes lldb-server's parsing more strict
and adds more tests to check that we handle negative types
correctly in lldb and lldb-server.

We only support one tag type value at this point,
for AArch64 MTE, which is positive. So this doesn't change
any of those interactions. It just brings us in line with GDB.

Also check that the test target has MTE. Previously
we just checked that we were AArch64 with a toolchain
that supports MTE.

Finally, update the tag type check for QMemTags to use
the same conversion steps that qMemTags now does.
Using static_cast can invoke UB and though we do do a limit
check to avoid this, I think it's clearer with the new method.

Reviewed By: omjavaid

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