to match StringMap and unordered_set.

[Clang][OpenMP] Fix the issue that `llvm.lifetime.end` is emitted too early for variables captured in linear clause

Currently if an OpenMP program uses `linear` clause, and is compiled with
optimization, `llvm.lifetime.end` for variables listed in `linear` clause are
emitted too early such that there could still be uses after that. Let's take the
following code as example:
```
// loop.c
int j;
int *u;

void loop(int n) {
  int i;
  for (i = 0; i < n; ++i) {
    ++j;
    u = &j;
  }
}
```
We compile using the command:
```
clang -cc1 -fopenmp-simd -O3 -x c -triple x86_64-apple-darwin10 -emit-llvm loop.c -o loop.ll
```
The following IR (simplified) will be generated:
```
@j = local_unnamed_addr global i32 0, align 4
@u = local_unnamed_addr global ptr null, align 8

define void @loop(i32 noundef %n) local_unnamed_addr {
entry:
  %j = alloca i32, align 4
  %cmp = icmp sgt i32 %n, 0
  br i1 %cmp, label %simd.if.then, label %simd.if.end

simd.if.then:                                     ; preds = %entry
  call void @llvm.lifetime.start.p0(i64 4, ptr nonnull %j)
  store ptr %j, ptr @u, align 8
  call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
  %0 = load i32, ptr %j, align 4
  store i32 %0, ptr @j, align 4
  br label %simd.if.end

simd.if.end:                                      ; preds = %simd.if.then, %entry
  ret void
}
```
The most important part is:
```
  call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
  %0 = load i32, ptr %j, align 4
  store i32 %0, ptr @j, align 4
```
`%j` is still loaded after `@llvm.lifetime.end.p0(i64 4, ptr nonnull %j)`. This
could cause the backend incorrectly optimizes the code and further generates
incorrect code. The root cause is, when we emit a construct that could have
`linear` clause, it usually has the following pattern:
```
EmitOMPLinearClauseInit(S)
{
  OMPPrivateScope LoopScope(*this);
  ...
  EmitOMPLinearClause(S, LoopScope);
  ...
  (void)LoopScope.Privatize();
  ...
}
EmitOMPLinearClauseFinal(S, [](CodeGenFunction &) { return nullptr; });
```
Variables that need to be privatized are added into `LoopScope`, which also
serves as a RAII object. When `LoopScope` is destructed and if optimization is
enabled, a `@llvm.lifetime.end` is also emitted for each privatized variable.
However, the writing back to original variables in `linear` clause happens after
the scope in `EmitOMPLinearClauseFinal`, causing the issue we see above.

A quick "fix" seems to be, moving `EmitOMPLinearClauseFinal` inside the scope.
However, it doesn't work. That's because the local variable map has been updated
by `LoopScope` such that a variable declaration is mapped to the privatized
variable, instead of the actual one. In that way, the following code will be
generated:
```
  %0 = load i32, ptr %j, align 4
  store i32 %0, ptr %j, align 4
  call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
```
Well, now the life time is correct, but apparently the writing back is broken.

In this patch, a new function `OMPPrivateScope::restoreMap` is added and called
before calling `EmitOMPLinearClauseFinal`. This can make sure that
`EmitOMPLinearClauseFinal` can find the orignal varaibls to write back.

Fixes #56913.

Reviewed By: ABataev

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

This has been deprecated since D116492 earlier in 2022.

That seems recent, but with the recent cut of LLVM 15 that is still two releases (14 and 15). Meanwhile Clang has deprecated `llvm-config` for a lot longer, and since it is likely that LLD users are also Clang users, this serves as an extra "heads up" that `llvm-config` is on its way out.

Remove it in favor of using CMake's find_package() function.

Reviewed By: MaskRay, mgorny

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

This has been deprecated for a while, since D51714 in 2018.

Remove it in favor of using CMake's find_package() function.

Reviewed By: phosek, mgorny

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

LLVM switched to C++17 in b1356504

- Fixes [[ https://github.com/llvm/llvm-project/issues/56787 | #56787 ]].

I am fixing the spelling of availability.

I am unsure if this change will have any side effects. If someone can
help on how to check if it has any side effects, I can test those out as
well.

Reviewed By: inclyc

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

All current in-tree users use the default implementation.

CTAD takes care of it.

Update some of the C99-era DRs starting in the 300s.

Implements part of:

* P1614R2 The Mothership has Landed

Reviewed By: #libc, Mordante

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

Implements part of:

  - P1614R2 The Mothership has Landed

Fixes LWG3426

Reviewed By: #libc, Mordante

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

This is for https://github.com/llvm/llvm-project/issues/56469

Allocate 4 bytes for float point arguments on PPC32.

Reviewed By: nemanjai

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

glibc annotates `process_vm_readv` with `__THROW`.
lldb/include/lldb/Host/linux/Uio.h and
lldb/source/Host/linux/LibcGlue.cpp don't.

Having a mismatch causes an error with c++17:

    ../../lldb/source/Host/linux/LibcGlue.cpp:18:9:
        error: 'process_vm_readv' is missing exception specification 'throw()'
    ssize_t process_vm_readv(::pid_t pid, const struct iovec *local_iov,
            ^
    ../../lldb/include/lldb/Host/linux/Uio.h:18:9:
        note: previous declaration is here
    ssize_t process_vm_readv(::pid_t pid, const struct iovec *local_iov,
            ^

The diagnostic is a bit misleading, since the previous declaration
in the sysroot (in usr/include/x76_64-linux-gnu/bits/uio-ext.h) is
what has the `__THROW`.

In the cmake build, cmake sets `HAVE_PROCESS_VM_READV` correctly based
on header probing.

In the GN build, just set it to 1 unconditionally on linux. If that
turns out to not be good enough everywhere, we'll have to add a GN arg
for this.

(I'm also setting it to 1 on Android. I'm not sure if that's correct --
but we don't build lldb for Android anyways.)

std::iterator has been deprecated in C++17 and some standard library implementations such as MS STL or libc++ emit deperecation messages when using the class.
Since LLVM has now switched to C++17 these will emit warnings on these implementations, or worse, errors in build configurations using -Werror.

This patch fixes these issues by replacing them with LLVMs own llvm::iterator_facade_base which offers a superset of functionality of std::iterator.

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

This has previously been done for `mlir-opt` and `mlir-reduce` and roughly the same approach has been done here.

The use case for having a separate library is that it is easier for downstream to make custom TableGen backends/executable that work on top of the utilities that are defined in `mlir/TableGen`.
The customization point here is the same one as for any upstream TableGen backends: One can add a new generator by simply creating a global instance of `mlir::GenRegistration`.

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

The function may be called currently for diagnostics.

Related tasks:

- SWDEV-240194
- SWDEV-309417
- SWDEV-334876

Reviewed By: arsenm

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

Also make the soft toolchain requirements hard. This allows
us to use C++17 features in LLVM now.

If we find patterns with C++17 that improve readability
it should be recommended in the coding standards.

Reviewed By: jhenderson, cor3ntin, MaskRay

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

In the case of static compilation the file system is pretty much read-only
and taking a snapshot of it usually is sufficient. In the interactive C++
case the compilation is longer and people can create and include files, etc.
In that case we often do not want to open files or cache failures unless is
absolutely necessary.

This patch extends the original API call by forwarding some optional flags,
so we can continue use it in the previous way with no breakage.
Signed-off-by: Jun Zhang <jun@junz.org>

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

    Looks like a typo from the past code changes.

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

D74537 introduced a bug: if `(config->andFeatures & GNU_PROPERTY_AARCH64_FEATURE_1_PAC) != 0`
with -z pac-plt unspecified, we incorrectly use AArch64BtiPac, whose writePlt will make
out-of-bounds write after the .plt section. This is often benign because the
output section after .plt will usually overwrite the content.

This is very difficult to test without D131247 (Parallelize writes of different OutputSections).

The place from D61712 seems unneeded now. We can just use the place added by
D62609 (support AArch64 BTI/PAC).

Some tests (e.g. aarch64-feature-pac.s) segfault in libstdc++ _GLIBCXX_DEBUG
builds (enabled by LLVM_ENABLE_EXPENSIVE_CHECKS).

dyn_cast<ThunkSection> is incorrectly true for any SyntheticSection. std::merge
transitively calls mergeCmp(x, x) (due to __glibcxx_requires_irreflexive_pred)
and will segfault in `ta->getTargetInputSection()`. The dyn_cast<ThunkSection>
issue should be eventually fixed properly, bug `a != b` is robust enough for now.

See revision b8b7a9dc for prior art.

When not set output, set default output to stdout.
When set output with -Fo and no -fcgl, set -emit-obj to generate dx container.

Reviewed By: beanz

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

When performing device only compilation, there was an issue where
`cubin` outputs were being renamed to `cubin` despite the user's name.
This is required in a normal compilation flow as the Nvidia tools only
understand specific filenames instead of checking magic bytes for some
unknown reason. We do not want to perform this transformation when the
user is performing device only compilation.

Reviewed By: tra

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

Use of `ORIGINAL_PCH_DIR` record has been superseeded by making PCH/PCM files with relocatable paths at write time.
Removing this record is useful for producing an output-path-independent PCH file and enable sharing of the same PCH file even
when it was intended for a different output path.

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

Fixes https://github.com/llvm/llvm-project/issues/56960

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

D91426 makes .got possibly empty while needed. If .got and .data have the same
address, and .got's content is written after .data, the first word of .data will
be corrupted.

The bug is not testable without D131247.