While doing a test-release.sh run on FreeBSD, I ran into a sed error due
to the introduction of the GNU extension '\s' in commit 500587e2.

Scanning for blanks (spaces and tabs) could be done in a more portable
fashion using the [[:blank:]] character class. But it is easier to avoid
the original problem, which is that the projects and runtime lists have
to be separated by semicolons, and cannot start with a semicolon.

Instead, use the shell's alternate value parameter expansion mechanism,
which makes it easy to append items to lists with separators in between,
and without any leading separator. This also avoids having to run sed on
the end result.

In addition, build any selected runtimes in the second phase, otherwise
the third phase can fail to find several symbols in compiler-rt, if that
has been built. This is because the host's compiler-rt is not guaranteed
to have those symbols.

Reviewed By: tstellar

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

This changes the sanitizers' tls_get_addr handling from
a heuristic check of __signal_safe_memalign allocations
(which has only been used in a since deprecated version
of Google's runtime), to using the sanitizers' interface
function to check if it is a malloc allocation (used
since glibc >= 2.25).

This is one of the approaches proposed by Keno in
https://github.com/google/sanitizers/issues/1409#issuecomment-1214244142

This moves the weak annotation of __sanitizer_get_allocated_size/begin from the header to sanitizer_tls_get_addr.cpp, as suggested by Vitaly in D148060.

Reviewed By: vitalybuka

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

Add missing dependency.

Handle nan.

This fix https://github.com/llvm/llvm-project/issues/61934

By default, the width property is used to set the width of a table column.
However, if the content of a cell in that column is wider than the width
specified by the width property, the cell's content will overflow the
column and the table will become wider than the specified width.
This causes the version numbers to be displayed outside of their table cells.

Using the min-width property instead of width ensures that the column is
wide enough to accommodate the content of its cells. If a cell's content is
wider than the specified min-width, the column will expand to fit the content.

Reviewed By: chelini

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

Towards replacing llvm::StringView with std::string_view, remove ctor
that std::string_view doesn't have an analog for.

Reviewed By: erichkeane, MaskRay

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

Make the fold use the information present in the condition for deducing constants i.e:
```
%c = icmp eq i8 %x, 10
%s = select i1 %c, i8 3, i8 2
%r = mul i8 %x, %s
```

If we fold the `mul` into the select, on the true side we insert `10` for `%x` in the `mul`.

Reviewed By: nikic

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

Reviewed By: nikic

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

Just seemed to be missing an assertion.

Reviewed By: sivachandra

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

Just add `__llvm_libc::` to makes things clearer.

Reviewed By: sivachandra

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

An intrusive reference counter uses less memory than the control
block of std::shared_ptr.

This should allow some additional code simplifications if we
don't need to pass around shared_ptr in order to create new
shared_ptrs.

The clang-tidy documentation contained:

> MS Visual Studio has a native clang-tidy-vs plugin

This plugin was removed via 559ae14c.

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

Reviewed By: PiotrZSL

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

Improve the (`D144510`)[https://reviews.llvm.org/D144510] patch with prefix string. Using "my" instead of "cust" would increase
readability.

Take some examples:
- const char* `custszNamePtr` = "Name"; --> `myszNamePtr`
- uint8_t `custu8ValueU8` = 0; --> `myu8ValueU8`
- DWORD `custdwMsDword` = 0; --> `mydwMsDword`

Reviewed By: PiotrZSL

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

[clang-tidy] Fix false positve for defaulted move constructor in performance-noexcept-move-constructor

Previously a struct like this:

template <typename>
struct A { A(A&&) = default; };

Would trigger a false positive, since even though it is not marked as
noexcept it still is due to the `= default`.
Now we only give a warning if the defaulted move constructor is
actually declared as throwing and correctly resolve it if they are
defaulted.

This fixes llvm#56026, llvm#41414, llvm#38081

Reviewed By: PiotrZSL

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

Towards converting our use of llvm::StringView to std::string_view,
remove a method that std::string_view doesn't have.
llvm::StringView::dropFront is semantically similar to
std::string_view::substr but with the input clamped to the size. No code
was relying on clamping other than the rust demangler, which I fixed in
https://reviews.llvm.org/D148272.  Removing this method makes it easier
to switch over code later.

Reviewed By: MaskRay

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

This ports D148280 for ASan.

On x86-64 Linux, when mmap_rnd_bits is set to 32 (the maximum `ARCH_MMAP_RND_BITS_MAX`),
the allocator space `[kAllocatorSpace,kAllocatorSpace+kAllocatorSize)`
collides with the PIE load base range (0x555555554000 upto `2**mmap_rnd_bits * pagesize` away),
which can cause the allocation to fail.
Using 0x500000000000ULL as the base address avoids this problem and works with
AArch64 Linux and FreeBSD as well.

While here, change s390x to use 0x500000000000ULL as well. See D78644
discussions that the address works.

Reviewed By: thurston, vitalybuka

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

This is a cheap pass so there's no need to limit to -O3.
This removes some differences between various pipelines.

Reviewed By: nikic

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

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

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

Last user of DemandedBitsWrapperPass was the BDCE pass. Since
the legacy PM version of BDCE was removed in an earlier commit, this
patch removes the now unused DemandedBitsWrapperPass.

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

BDCE is not used by the codegen pipeline so we should not need the
legacy PM version of the pass any longer.

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

Fix destructors being incorrectly defined in the DefineOutline tweak
Currently it doesn't prepend the class name to the destructor
```lang=c++
class A { ~A() {} };
// Destructor definition after outline
~A() {}
// After this fix
A::~A() {}
```

Reviewed By: kadircet

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

With a previous patch to canonicalize SPF to min/max intrinsics (a266af72),
we saw a performance regression on the AArch64 backend.

This patch recovers from the SPF canonicalization by combining smin(a,0) and
smax(a,0) SELECT_CC patterns during AArch64ISelLowering.

GitHub Issue: #61767

Reviewed By: dmgreen

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

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

Lower the parse tree to acc dialects operations. Make use
of the compute construct lowering.

Depends on D148277

Reviewed By: PeteSteinfeld

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

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

Toward the goal of replacing llvm::StringView with std::string_view,
first replacing users of llvm::StringView::dropFront, this case in the
Rust demangling scheme seemed worth its own commit+review.

Reviewed By: erichkeane, MaskRay

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

**Summary**

In a program such as:
```
namespace A {
namespace B {
struct Bar {};
}
}

namespace B {
struct Foo {};
}
```
...LLDB would run into issues such as:
```
(lldb) expr ::B::Foo f
error: expression failed to parse:
error: <user expression 0>:1:6: no type named 'Foo' in namespace 'A::B'
::B::Foo f
~~~~~^
```

This is because the `SymbolFileDWARF::FindNamespace` implementation
will return *any* namespace it finds if the `parent_decl_ctx` provided
is empty. In `FindExternalVisibleDecls` we use this API to find the
namespace that symbol `B` refers to. If `A::B` happened to be the one
that `SymbolFileDWARF::FindNamespace` looked at first, we would try
to find `struct Foo` in `A::B`. Hence the error.

This patch proposes a new `SymbolFileDWARF::FindNamespace` API that
will only find a match for top-level namespaces, which is what
`FindExternalVisibleDecls` is attempting anyway; it just never
accounted for multiple namespaces of the same name.

**Testing**

* Added API test-case

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

Summary:
At some point we stopped copying this file to the server, but
realistically this is just a static `.pdf` hosted in the LLVM repository
so we can link it directly.

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

This patch allows users to evaluate expressions using
`expr -l c++20`. Currently DWARF keeps the CU's at
`DW_AT_language` at `DW_LANG_C_plus_plus_14` even
when compiling with `-std=c++20`. So even in "C++20
programs" expression evaluation will by default be
performed in `C++11` mode for now.

Enabling `C++14` has been previously attempted at
https://reviews.llvm.org/D80308

There are some remaining issues around evaluating C++20
expressions. Mainly, lack of support for C++20 AST nodes in
`clang::ASTImporter`. But these can be addressed in follow-up
patches.

Adds more languages to the `language_names` list in
preparation for adding support for C++20 expression
evaluation.

The language constants were taken from the DWARFv5
constants defined in LLVM's `Dwarf.def`. Two vendor
constants overlap with the DWARFv5 constants so bump
their values. Their actual value is not important,
whereas keeping the enum values consecutive is (since
they are used for array lookups).

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

This test fails on several aarch64 bots
  clang-aarch64-lld-2stage ( https://lab.llvm.org/buildbot/#/builders/185/builds/3525 )
  clang-aarch64-full-2stage ( https://lab.llvm.org/buildbot/#/builders/179/builds/5904 )
  clang-aarch64-sve-vla ( https://lab.llvm.org/buildbot/#/builders/197/builds/4519 )
Disable it while this is analyzed.

Reviewed By: DavidSpickett

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

The acc.kernels operation models the OpenACC kernels construct.
The kernels construct defines a region of a program that is
compiled into a sequence of kernels to be executed on the current device.
The operation is modelled on the acc.parallel operation and will
receive similar updates when the data operands operations will
be implemented.

Reviewed By: PeteSteinfeld

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