This was initially reported here (including stacktraces):
https://stackoverflow.com/questions/78183545/does-compiling-imagick-with-openmp-enabled-in-freebsd-13-2-cause-sched-yield

If `__kmp_register_library_startup()` detects that another instance of
the library is present, `__kmp_is_address_mapped()` is eventually
called. which uses `kmpc_alloc()` to allocate memory. This function
calls `__kmp_entry_thread()` to access the thread-local memory pool,
which is a bad idea during initialization. This macro internally calls
`__kmp_get_global_thread_id_reg()` which sets the bootstrap lock at the
beginning (before calling `__kmp_register_library_startup()`).

The fix is to use `KMP_INTERNAL_MALLOC()`/`KMP_INTERNAL_FREE()` instead
of `kmpc_malloc()`/`kmpc_free()`. `KMP_INTERNAL_MALLOC` and
`KMP_INTERNAL_FREE` do not use any bootstrap locks. They just translate
to `malloc()`/`free()` and are meant to be used during library
initialization before other library-specific allocators have been
initialized.

Fixes: #86684

This reverts commit 8a071678.

The test failure on 32-bit Arm should have been fixed by #86892.

cc @nickdesaulniers @lntue

Add the "nowait" clause to the list of allowed clauses for the "workshare"
directive. This will make it consistent with other directives (which are
shared between C/C++ and Fortran).

The parser will still reject "nowait" on "!$omp workshare", so this has no
effect on accepting/rejecting Fortran source code.

According to
https://protobuf.dev/reference/protobuf/textformat-spec/#text-format-files

,
txtpb is the canonical extension

Co-authored-by: Jing Wang <99jingw@gmail.com>

https://github.com/llvm/llvm-project/pull/84542

Fix static analyzer concerns about dereferencing
null values.

There's so much overlap between the cited papers so this condenses the
status page into a single entry rather than trying to test conformance
against multiple papers doing conflicting things.

RecordWriter does not live past the end of writeMemProfRecords, so it
can be safely on stack.

The constructor of FrameWriter does not take any parameter, so we can
let OnDiskChainedHashTableGenerator::Emit (with a single parameter)
default-construct an instance of the writer trait inside Emit.

Reapply "Fix error in unrecognized register name handling for "SBFram…e.register"" (#88468)" (#88535)

The only change is a fix for the "register" iterator test to not rely on
particular register names.

I mistook where the artificial "pc" register is generated. It isn't
added to the register list or the register sets (except on arm where
that's the name of the actual register), so I can't use it in this test.
I instead just assert that the "register" generator produces the same
list as flattening the register sets from "registers".

This reverts commit 9f149147.

`__xray_customevent` and `__xray_typedevent` are built-in functions in
Clang. With -fxray-instrument, they are lowered to `__xray_CustomEvent`
(with 2 arguments) or `__xray_TypedEvent` (with 3 arguments).

xray patching is supported for shared objects, but they may contain
`__xray_customevent` and `__xray_typedevent` references that need to be
satisfied by default visibility definitions exported by the executable.

lld since df54f627, like GNU ld, catches
the scenario at link time.

Caused by commit edd7fed9

Android now supports both 4kB and 16kB page sizes. The vast majority of
android apps are developed on x86_64 machines. In order to provide
emulators that support larger page sizes, Android emulates the page-size
in x86_64 to support testing apps for large page size support.

For this reason, update Android x86_64 ELFs default max-page-size to
16384 to support both 4kB and 16kB page-size devices.

Increase max-page-size raises concerns of increased disk space and extra
VMA slab memory.

In Android, RO partitions use sparse images, so that the holes on ELFs
don't allocate blocks on disk; and PackageManager ensures to punch holes
in ELF-paddings on the /data partition when apps are installed.

Extra VMA slab memory is addressed by the bionic loader, which extends
segment VMAs to cover the gaps between consecutive segment mappings, to
avoid the extra VMAs needed for the gap PROT_NONE mappings (---p). This
optimization is done in the crt_pad_segment note [1] is present in the
ELF.

[1]
https://cs.android.com/android/platform/superproject/main/+/189e480390ef13199d59e1fb54078e8b78ea6f79:bionic/libc/arch-common/bionic/crt_pad_segment.S



---------

Signed-off-by: Kalesh Singh <kaleshsingh@google.com>
Co-authored-by: Kalesh Singh <kaleshsingh@google.com>

This PR starts caching calls to
`DependencyScanningWorkerFilesystem::getRealPath()` that we use whenever
we canonicalize module map path. In the case of the real VFS, this
functions performs an expensive syscall that we'd like to do as rarely
as possible.

This PR keeps the real path out of `CachedFileSystemEntry`, since that's
**immutable**; populating the real path on creation of this data
structure (every stat/open) would be expensive.

This is an NFC change split from https://github.com/llvm/llvm-project/pull/68645.

This is an NFC change split from https://github.com/llvm/llvm-project/pull/68645.

This is an NFC change split from https://github.com/llvm/llvm-project/pull/68645.

## Abstract

This pull request implements [P3029R1](https://wg21.link/P3029R1). The
paper discusses the current behavior of `mdspan`'s most common
pointer-indices CTAD, where the `Extents` template parameter is deduced
as `dextents` (dynamic extents), even when passing compile-time constant
values. The author believes this behavior is suboptimal, as it doesn't
take advantage of the compile-time information. The proposed change
suggests deducing static extents if `integral_constant`-like constants
are passed, resulting in more intuitive syntax and less error-prone
code.

## Reference

- [P3029R1](https://wg21.link/P3029R1)
- [Draft C++ Standard: [span.syn]](https://eel.is/c++draft/span.syn)
- [Draft C++ Standard: [mdspan.syn]](https://eel.is/c++draft/mdspan.syn)

This applies the same rules we have for the scalar operands of a
BUILD_VECTOR where the scalar type must match the element type or for
integer vectors we allow the scalar type to be larger than the element
type. Hexagon uses i32 for an FP zero vector so we allow that as an
exception.

Needed for the future patch.

Commit d06b9239 caused a regression that breaks after a block
comment adjacent to a function paramter that follows.

Fixes #86573.

In 4d5e834c, casts were removed for
pointers but one case was missed. Add missing check.

Some functions allow a null SourceManager, no SourceManager, or a
SourceManager in an inconsistent argument position. Since SourceManager
is generally not null and it doesn't make sense to apply renaming
without one, these inconsistencies are now gone.

For e0a62871

Making the clang resource headers into an interface library instead of a
custom target means that we can attach the header search paths to the
library. Targets that "link" against this library will automatically
have the appropriate paths added to their header search paths to find
them. Then downstream projects that embed a copy of clang can query the
generated `ClangTargets.cmake` file for the header location instead of
attempting to compute them.

This commit skips the expansion of the `vector.reduce.add` intrinsic on
vector-enabled SystemZ targets in order to introduce custom handling of
`vector.reduce.add` for legal vector types using the VSUM instructions.
This is limited to full vectors with scalar types up to `i32` due to
performance concerns.

It also adds testing for the generation of such custom handling, and
adapts the related cost computation, as well as the testing for that.

The expected result is a performance boost in certain benchmarks that
make heavy use of `vector.reduce.add` with other benchmarks remaining
constant.

For instance, the assembly for `vector.reduce.add<4 x i32>` changes from
```hlasm
        vmrlg   %v0, %v24, %v24
        vaf     %v0, %v24, %v0
        vrepf   %v1, %v0, 1
        vaf     %v0, %v0, %v1
        vlgvf   %r2, %v0, 0
```
to
```hlasm
        vgbm    %v0, 0
        vsumqf  %v0, %v24, %v0
        vlgvf   %r2, %v0, 3
```

### Assembly Tests
This adds assembly tests for 
```
lcdfr, lndfr, lpdfr
```

### Disassembly Tests
This also adds a number of disassembly tests for the following
menmonics:
```
cgit, cgrt, cit, clfit, clgit, clgrt, clgt, clrt, clt, crt, lcdfr, lndfr, lpdfr
```
For `cutfu` / `cu12`, it also adds a check for bad register choice.

Tensor copy insertion currently uses memory_space = 0 when creating a
tensor copy using alloc_tensor. This memory space should instead be the
default memory space provided in bufferization options.

This patch converts `isKnownNonZero` to use SimplifyQuery. Then we can
use the context information from `DomCondCache`.

Fixes https://github.com/llvm/llvm-project/issues/85823.
Alive2: https://alive2.llvm.org/ce/z/QUvHVj

lr.[wd]: mayLoad = 1, mayStore = 0
sc.[wd]: mayLoad = 0, mayStore = 1

all other AMOs: mayLoad = 1, mayStore = 1

This allows us to support larger stack offsets for FrameLowering.

Fixes #88365.

Use the std `if () continue;` idiom before falling into the
processing.

FormatManager::GetCategoryForLanguage and
FormatManager::GetCategory(can_create = true) can be called concurrently
and they both take the TypeCategory::m_map_mutex and the
FormatManager::m_language_categories_mutex but in reverse order.

On one thread, GetCategoryForLanguage takes m_language_categories_mutex
and then ends calling TypeCategoryMap::Get which takes m_map_mutex

On another thread GetCategory calls TypeCategoryMap::Add which takes
m_map_mutex and then calls FormatManager::Changed() which takes
m_language_categories_mutex

If both threads are running concurrently, we have a dead lock.

The patch releases the m_map_mutex before calling Changed which avoids
the dead lock.

---------

Co-authored-by: Vincent Belliard <v-bulle@github.com>

ROCm installation path is used for finding and automatically linking
required bitcode libraries for OpenMP AMDGPU offload.

Reported issue: https://github.com/llvm/llvm-project/issues/82553

This PR fix a AST dump issue since
https://github.com/llvm/llvm-project/pull/80001



When Clang dumps `CXXDefaultArgExpr`/`CXXDefaultInitExpr`, there has no
recursively dump the complete `CXXDefaultArgExpr`/`CXXDefaultInitExpr`.

Since this PR, Clang will recursively dump a
`CXXDefaultArgExpr`/`CXXDefaultInitExpr` node, even if the node has no
rewritten init.

*Consider*:
```
struct A {
  int arr[1];
};

struct B {
  const A &a = A{{0}};
};

void test() {
  B b{};
}
```

*Before*:
```
`-FunctionDecl <line:9:1, line:11:1> line:9:6 test 'void ()'
  `-CompoundStmt <col:13, line:11:1>
    `-DeclStmt <line:10:3, col:8>
      `-VarDecl <col:3, col:7> col:5 b 'B' listinit
        `-InitListExpr <col:6, col:7> 'B'
          `-CXXDefaultInitExpr <col:7> 'const A' lvalue has rewritten init
            `-ExprWithCleanups <line:6:16, col:21> 'const A' lvalue
```

*After*:
```
`-FunctionDecl 0x15a9455a8 <line:9:1, line:11:1> line:9:6 test 'void ()'
  `-CompoundStmt 0x15a945850 <col:13, line:11:1>
    `-DeclStmt 0x15a945838 <line:10:3, col:8>
      `-VarDecl 0x15a945708 <col:3, col:7> col:5 b 'B' listinit
        `-InitListExpr 0x15a9457b0 <col:6, col:7> 'B'
          `-CXXDefaultInitExpr 0x15a9457f8 <col:7> 'const A' lvalue has rewritten init
            `-ExprWithCleanups 0x15a945568 <line:6:16, col:21> 'const A' lvalue
              `-MaterializeTemporaryExpr 0x15a945500 <col:16, col:21> 'const A' lvalue extended by Field 0x15a945160 'a' 'const A &'
                `-ImplicitCastExpr 0x15a9454e8 <col:16, col:21> 'const A' <NoOp>
                  `-CXXFunctionalCastExpr 0x15a9454c0 <col:16, col:21> 'A' functional cast to A <NoOp>
                    `-InitListExpr 0x15a9452c0 <col:17, col:21> 'A'
                      `-InitListExpr 0x15a945308 <col:18, col:20> 'int[1]'
                        `-IntegerLiteral 0x15a945210 <col:19> 'int' 0
```

---------

Signed-off-by: yronglin <yronglin777@gmail.com>

This includes the lldb-dap executable in the MacOS and Linux
distributions of Swift. Currently there is a commit in the Apple repo to
do this for just MacOS https://github.com/apple/llvm-project/pull/8176.
This PR extends this to both Linux and MacOS and brings the change
upstream.

@JDevlieghere @adrian-prantl

The load narrowing part of TargetLowering::SimplifySetCC is updated
according to this:

1) The offset calculation (for big endian) did not work properly for
   non byte-sized types. This is basically solved by an early exit
   if the memory type isn't byte-sized. But the code is also corrected
   to use the store size when calculating the offset.
2) To still allow some optimizations for non-byte-sized types the
   TargetLowering::isPaddedAtMostSignificantBitsWhenStored hook is
   added. By default it assumes that scalar integer types are padded
   starting at the most significant bits, if the type needs padding
   when being stored to memory.
3) Allow optimizing when isPaddedAtMostSignificantBitsWhenStored is
   true, as that hook makes it possible for TargetLowering to know
   how the non byte-sized value is aligned in memory.
4) Update the algorithm to always search for a narrowed load with
   a power-of-2 byte-sized type. In the past the algorithm started
   with the the width of the original load, and then divided it by
   two for each iteration. But for a type such as i48 that would
   just end up trying to narrow the load into a i24 or i12 load,
   and then we would fail sooner or later due to not finding a
   newVT that fulfilled newVT.isRound().
   With this new approach we can narrow the i48 load into either
   an i8, i16 or i32 load. By checking if such a load is allowed
(e.g. alignment wise) for any "multiple of 8 offset", then we can find
   more opportunities for the optimization to trigger. So even for a
   byte-sized type such as i32 we may now end up narrowing the load
   into loading the 16 bits starting at offset 8 (if that is allowed
   by the target). The old algorithm did not even consider that case.
5) Also start using getObjectPtrOffset instead of getMemBasePlusOffset
   when creating the new ptr. This way we get "nsw" on the add.

These test cases show some miscomplies for big-endian when dealing
with non byte-sized loads. One part of the problem is that LLVM IR
isn't really telling where the padding goes for non byte-sized
loads/stores. So currently TargetLowering::SimplifySetCC can't assume
anything about it. But the implementation also do not consider that
the TypeStoreSize could be larger than the TypeSize, resulting in
the offset calculation being wrong for big-endian.

Pre-commit for https://github.com/llvm/llvm-project/pull/87646

[lldb][test] Add tests for evaluating local variables whose name clashes with Objective-C types (#87807)

Depends on https://github.com/llvm/llvm-project/pull/87767