This is to avoid spurious test failures in case apple-clang-14 doesn't
support _BitInt.

(cherry picked from commit 87b218b4)

Reported by Stefan Pintilie in D119773.

For a branch to a hidden undefined weak symbol, there is an
`assert(sym->getVA());` failure in PPC64LongBranchTargetSection::writeTo for a
-no-pie link. The root cause is that we unnecessarily create the thunk for the
-no-pie link.

Fix this by changing the condition to just `s.isUndefined()`. See the inline
comment.

Rename ppc64-weak-undef-call.s to ppc64-undefined-weak.s to be consistent with
other architectures.

Reviewed By: sfertile, stefanp

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

(cherry picked from commit 53b59fdc)

Also, fix the actual code so that the test would pass if we fixed the
issue that the method is instantiated in the dylib, and hence the debug
assertion will never fire except if the debug mode is enabled when the
dylib is being compiled.

(cherry picked from commit 5c53afe5)

This works around a known issue in ASan. ASan doesn't instrument weak
symbols. Because instrumentation increases object size, the binary can
end up with two versions of the same object, one instrumented and one
not instrumented, with different sizes, which ASan will report as an ODR
violation. In libc++, this affects typeinfo for `std::bad_function_call`
which is emitted as a weak symbol in the test executable and as a strong
symbol in the shared library.

The main open issue for ASan appears to be
https://github.com/google/sanitizers/issues/1017.

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

(cherry picked from commit 10953974)

This wasn't caught because we don't test the combination of no-filesystem
and no-experimental-features in the CI.

(cherry picked from commit 7dad5f84)

The logic here is that we are disabling *only* things in `std::ranges::`.
Everything in `std::` is permitted, including `default_sentinel`, `contiguous_iterator`,
`common_iterator`, `projected`, `swappable`, and so on. Then, we include
anything from `std::ranges::` that is required in order to make those things
work: `ranges::swap`, `ranges::swap_ranges`, `input_range`, `ranges::begin`,
`ranges::iter_move`, and so on. But then that's all. Everything else (including
notably all of the "views" and the `std::views` namespace itself) is still
locked up behind `_LIBCPP_HAS_NO_INCOMPLETE_RANGES`.

Originally reviewed as https://reviews.llvm.org/D118736.

(cherry picked from commit 53406fb6)

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

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

If we assume `llvm.amdgcn.s.barrier` is aligned we may remove it and
cause OpenMP GPU applications on the AMD GPU to be stuck or wrongly
synchronized.

Reported by Carlo Bertolli.

(cherry picked from commit ede248e6)

If we had some source value we could infer an address space from that
went through a ptrtoint/inttoptr pair, this would fail since bitcast
can't change the address space.

Fixes issue 53665.

(cherry picked from commit 52fbb786)

For the release/14.x branch.

Reviewed By: alexander-shaposhnikov, jhenderson

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

As explained in the comment, we don't have macOS 10.15 builders anymore
in the fleet. Enabling those tests on the release branch would require
cherry-picking too many changes from `main`.

This reverts commit 5ebdb07e.

Enabling shrink wrap by default can cause assertions or crashes, and
these should first be investigated and fixed. For now, reverting the
change so it can be cherry-picked into 14.0.0 is the safest choice.

(cherry picked from commit 7af3d4ab)

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

(cherry picked from commit 287ce6b5)

This is an alternative to D118667 that instead of fixing the store
to match phase 1, it tries to detect the mismatch with the expected
value at the end of the block. This inserts a vsetvli after the vse
to satisfy the requirement of the other basic block.

We still have serious design issues in the pass, that is going to
require some rethinking.

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

(cherry picked from commit 541c9ba8)

Revert "[RISCV] Fix a vsetvli insertion bug involving loads/stores." and "[RISCC] Add missing words to comment. NFC"

This reverts commit f943c58c.
and commit 7eb78107.

This introduced a new bug that appears to be easier to hit.

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

(cherry picked from commit f35ac872)

We're missing a vsetvli before a vse after a redsum in this test.

This appears to be because the vmv.s.x has a VL of 1, but did not
trigger a vsetvli because it is a scalar move op and any non-zero
VL would work. So it looked at it the predecessors and decided it was
that they all had a non-zero vl. Then the redsum was visited, it
also took the VL from the predecessors since the vmv.s.x and the 4
was found compatible.

Finally we visit the vse and it looks at the BBLocalInfo and sees
that is compatible because it contains a VL of 1 from the vmv.s.x,
the first instruction in the block. BBLocalInfo was not updated
when the vredsum was visited because BBLocalInfo was valid and no
vsetvli was generated.

I think fundamentally the vmv.s.x optimization has the same first
phase and third phase not matching problem that D118667 was trying
to fix for stores.

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

(cherry picked from commit ba9a7ae7)

MSVC does not support variable length arrays. Replace with KMP_ALLOCA
which is already used in the same file for stack-allocated variables.

(cherry picked from commit 6be7c21b)

(cherry picked from 2937b282)

This reverts commit 0df52296.

Additional checks are added to fix the detection of the last memory region
in GetMemoryRegions or repeating the "memory region" command when the
target has non-address bits.

Normally you keep reading from address 0, looking up each region's end
address until you get LLDB_INVALID_ADDR as the region end address.
(0xffffffffffffffff)

This is what the remote will return once you go beyond the last mapped region:
[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0001000000000000-0xffffffffffffffff) ---

Problem is that when we "fix" the lookup address, we remove some bits
from it. On an AArch64 system we have 48 bit virtual addresses, so when
we fix the end address of the [stack] region the result is 0.
So we loop back to the start.

[0x0000fffffffdf000-0x0001000000000000) rw- [stack]
[0x0000000000000000-0x000...

This patch fixes the issue that the for loop in `applyToShadowMapEntries`
is infinite because `Itr` is not incremented in `CB`. Fixes #53727.

Reviewed By: jdoerfert

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

(cherry picked from commit c27f530d)

Instead of using the deprecated LLVM_ENABLE_PROJECTS build, use the
default runtimes build. This is just as fast, but it's supported.

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

(cherry picked from commit f34f7dfe)

We experienced some deadlocks when we used multiple threads for logging
using `scan-builds` intercept-build tool when we used multiple threads by
e.g. logging `make -j16`

```
(gdb) bt
#0  0x00007f2bb3aff110 in __lll_lock_wait () from /lib/x86_64-linux-gnu/libpthread.so.0
#1  0x00007f2bb3af70a3 in pthread_mutex_lock () from /lib/x86_64-linux-gnu/libpthread.so.0
#2  0x00007f2bb3d152e4 in ?? ()
#3  0x00007ffcc5f0cc80 in ?? ()
#4  0x00007f2bb3d2bf5b in ?? () from /lib64/ld-linux-x86-64.so.2
#5  0x00007f2bb3b5da27 in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#6  0x00007f2bb3b5dbe0 in exit () from /lib/x86_64-linux-gnu/libc.so.6
#7  0x00007f2bb3d144ee in ?? ()
#8  0x746e692f706d742f in ?? ()
#9  0x692d747065637265 in ?? ()
#10 0x2f653631326b3034 in ?? ()
#11 0x646d632e35353532 in ?? ()
#12 0x0000000000000000 in ?? ()
```

I think the gcc's exit call caused the injected `libear.so` to be unloaded
by the `ld`, which in turn called the `void on_unload() __attribute__((destructor))`.
That tried to acquire an already locked mutex which was left locked in the
`bear_report_call()` call, that probably encountered some error and
returned early when it forgot to unlock the mutex.

All of these are speculation since from the backtrace I could not verify
if frames 2 and 3 are in fact corresponding to the `libear.so` module.
But I think it's a fairly safe bet.

So, hereby I'm releasing the held mutex on *all paths*, even if some failure
happens.

PS: I would use lock_guards, but it's C.

Reviewed-by: NoQ

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

(cherry picked from commit d919d027)

[test-release.sh] Set TEST_SUITE_HOST_CC to the release testing build compiler when compiling test-suite tools.

The tools used by test-suite are originally configured to compile with cc by
default, and this is dictated by TEST_SUITE_HOST_CC.
However, it is possible that on some systems that the version of cc may either
not be present or it may not be able to compile the tools as it may be too old,
which could be an issue seen during release testing.

This patch updates the compiler to be the default build compiler that is used
for release testing. If no such compiler it specified, then cc will be set as
the test-suite tools build compiler by default (as it already is set under
TEST_SUITE_HOST_CC).

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

(cherry picked from commit 413b35cd)

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

(cherry picked from commit 079b6d02)

OpenCL C 3.0 __opencl_c_subgroups feature is slightly different
then other equivalent features and extensions (fp64 and 3d image writes):
OpenCL C 3.0 device can support the extension but not the feature.
cl_khr_subgroups requires subgroup independent forward progress.

This patch adjusts the check which is used when translating language
builtins to check either the extension or feature is supported.

Reviewed By: Anastasia

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

(cherry picked from commit bfb1a33b)

OpenCL C 3.0 introduces optionality to some builtins, in particularly
to those which are conditionally supported with pipe, device enqueue
and generic address space features.

The idea is to conditionally support such builtins depending on the language options
being set for a certain feature. This allows users to define functions with names
of those optional builtins in OpenCL (as such names are not reserved).

Reviewed By: Anastasia

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

(cherry picked from commit bee4bd70)

Add the atomic overloads for the `global` and `local` address spaces,
which are new in OpenCL 3.0.  Ensure the preexisting `generic`
overloads are guarded by the generic address space feature macro.

Ensure a subset of the atomic builtins are guarded by the
`__opencl_c_atomic_order_seq_cst` and `__opencl_c_atomic_scope_device`
feature macros, and enable those macros for SPIR/SPIR-V targets in
`opencl-c-base.h`.

Also guard the `cl_ext_float_atomics` builtins with the atomic order
and scope feature macros.

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

(cherry picked from commit 50f8abb9)

Reduce the amount of repetition in the declarations by leveraging more
TableGen constructs.  This is in preparation for adding the OpenCL 3.0
atomics feature optionality.

(cherry picked from commit 8d370435)

An error in the tablegen description affects the declarations
provided by `-fdeclare-opencl-builtins` for `atomic_fetch_add` and
`atomic_fetch_sub`.

The atomic argument should be an atomic_half, not an atomic_float.

(cherry picked from commit fe690587)

This is in preparation for adding the OpenCL 3.0 builtins with named
address space arguments.

(cherry picked from commit 31fa3a4d)

This will simplify future conditionalization for OpenCL 3.0
optionality of atomic features.

The only set of atomic functions not using the multiclass is
atomic_compare_exchange_strong/weak, as these don't fit the common
pattern due to having 2 MemoryOrder arguments.

(cherry picked from commit d97a4dfe)

But only test in combination with -finclude-default-header, as the
headerless tests may be dropped soon.

(cherry picked from commit e0e6f3a6)

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

Reviewed By: MyDeveloperDay, HazardyKnusperkeks, owenpan

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

(cherry picked from commit e329b586)

Ensure CLANG_PLUGIN_SUPPORT is compatible with llvm_add_library.
Fixes an issue noted in D111100.

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

(cherry picked from commit 76cad51b)

This is no-functional-change-intended because only the
x86 target enables the TLI hook currently.

We can add fmul/fdiv opcodes to the switch similar to the
proposal D119111, but we don't need to make other changes
like enabling target-specific combines.

We can also add integer opcodes (add, or, shl, etc.) to
the switch because this function is called from all of the
generic binary opcodes.

The goal is to incrementally enable the profitable diffs
from D90113 while avoiding regressions.

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

(cherry picked from commit a68e0980)

This patch adds an option (no-clang-tools) to disable building clang-tools-extra when
performing release testing. Prior to this patch, clang-tools-extra was built by default,
but on some platforms (such as AIX), clang-tools-extra is not supported, and so we do
not normally build it. Furthermore, this change should not change the invocation for
targets that build clang-tools-extra normally.

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

(cherry picked from commit db691903)

This ensures that the Windows unwinder will work at every instruction
boundary, and allows other targets to read and write flags without
setting up a frame pointer.

Fixes GH-46875

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

(cherry picked from commit f3481f43)

When we privatize a pointer (~argument promotion) we introduce new
private allocas as replacement. These need to be placed in the alloca
address space as later passes cannot properly deal with them otherwise.

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

(cherry picked from commit e39b4193)

For the release/14.x branch.

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