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

This fixes Linux musl build after D118423.

(cherry picked from commit da2a16f7)

This reverts commit 2722ac65. As explained in D115906, this was actually
unnecessary and it broke the external threading configuration.

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

(cherry picked from commit c74b1924)

(cherry picked from commit 6a7f6e94)

VS2019 version 1920 in now the default and get tested in
llvm/include/llvm/Support/Compiler.h. This patch propagates
LLVM_FORCE_USE_OLD_TOOLCHAIN macro to disable testing for VS2019.

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

clang-cl MSVC required version is 19.20 now. Update the default
-fms-compatibility-version to 19.20.

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

D116208 may cause a macro clash on older versions of linux, where
fs.h defines a READ macro. This is resolved by switching to a more
typical casing style for non-macro symbols.

Reapplying with changes to the symbol names in various platform
specific code, which I missed previously.

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

(cherry picked from commit 36cae429)

Fix passing the port and IP address with the wrong endianness
in get_sock_peer_name() that causes the connect() to fail inside
without an outgoing network interface (it's trying to connect
to 1.0.0.127 instead of 127.0.0.1).

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

(cherry picked from commit c65fb0cd)

This reverts commit 83620bd2.

It's causing miscompilations, see review comments at
https://reviews.llvm.org/D115955

(cherry picked from commit 0c3d22a5)

This brings the mingw build back to zero build warnings as it was
at some earlier time.

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

(cherry picked from commit 8cffea06)

We are moving away from building the runtimes with LLVM_ENABLE_PROJECTS,
however the documentation was largely outdated. This commit updates all
the documentation I could find to use LLVM_ENABLE_RUNTIMES instead of
LLVM_ENABLE_PROJECTS for building runtimes.

Note that in the near future, libcxx, libcxxabi and libunwind will stop
supporting being built with LLVM_ENABLE_PROJECTS altogether. I don't know
what the plans are for other runtimes like libc, openmp and compiler-rt,
so I didn't make any changes to the documentation that would imply
something for those projects.

Once this lands, I will also cherry-pick this on the release/14.x branch
to make sure that LLVM's documentation is up-to-date and reflects what
we intend to support in the future.

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

(cherry picked from commit 4ae83bb2)

Neither LLDB nor GDB seem to work with DWARF 5 debug information on
Windows right now.

This applies the same change as in
9c627286 (Default to DWARFv4 on Windows)
to the MinGW driver too.

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

(cherry picked from commit 6cf64b2d)

I think this was just being ignored before, but now it crashes because
we're checking if the projects that we're trying to enable are valid.
There is no test-suite project (it's a separate repo with separate
handling), so we should never try to enable it.

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

The warning was introduced with the recently merged SPARCv9
support in 2b9554b8.

The cast matches the existing surrounding cases.

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

(cherry picked from commit dfa5ab7b)

See https://github.com/llvm/llvm-project/issues/53660

We are removing support for the Standalone build altogether on the main
branch, so this is going to help give an additional heads up to users
that don't read our release notes.

Also, as a fly-by fix, fixup incorrect documentation for libcxxabi and
mention libunwind in our release notes.

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

Remove the vector base class as suggested by @ldionne

Reviewed By: ldionne, Quuxplusone, #libc

Spies: libcxx-commits, ldionne

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

(cherry picked from commit b82da8b5)

The above change assumed that malloc (and friends) would always
allocate memory to getNewAlign(), even for allocations which have a
smaller size. This is not actually required by spec (a 1-byte
allocation may validly have 1-byte alignment).

Some real-world malloc implementations do not provide this guarantee,
and thus this optimization is breaking programs.

Fixes #53540

This reverts commit c2297544.

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

(cherry picked from commit 9545976f)

The original warning added in D115501 when pacbti is used with an
incompatible architecture was not exactly correct because it was
not really ignored and can affect codegen.

Therefore reword to say that the pacbti option is incompatible with
the given architecture.

Reviewed By: chill

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

(cherry picked from commit 424e850f)

While investigating the failures of `symbolize_pc.cpp` and
`symbolize_pc_inline.cpp` on SPARC (both Solaris and Linux), I noticed that
`__builtin_extract_return_addr` is a no-op in `clang` on all targets, while
`gcc` has non-default implementations for arm, mips, s390, and sparc.

This patch provides the SPARC implementation.  For background see
`SparcISelLowering.cpp` (`SparcTargetLowering::LowerReturn_32`), the SPARC
psABI p.3-12, `%i7` and p.3-16/17, and SCD 2.4.1, p.3P-10, `%i7` and
p.3P-15.

Tested (after enabling the `sanitizer_common` tests on SPARC) on
`sparcv9-sun-solaris2.11`.

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

(cherry picked from commit efdd0a29)

(cherry picked from commit 99580e29)

This is an intentionally limited/different form of D90113.
That patch bravely tries to generalize folds where we pull
a binop into the arms of a select:
N0 + (Cond ? 0 : FVal) --> Cond ? N0 : (N0 + FVal)
...but it is not universally profitable.

This is the inverse of IR canonicalization as discussed in
D113442.

We know that this transform is not entirely profitable even
within x86, so we only handle x86 vector fadd/fsub as a 1st
step. The intent is to prevent AVX512 regressions as mentioned
in D113442.

The plan is to port this to DAGCombiner (so it will eventually
look more like D90113) and add more types/cases in pieces with
many more tests to verify that we are seeing improvements.

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

(cherry picked from commit 6592bcec)

This patch drops throws specifier in posix_memalign declaration because
that's different between glibc and other libc, and Clang has a hack.

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

(cherry picked from commit f2f4080c)

The documentation for the official (downstream) Qualcomm Hexagon Clang
states that -mhvx sets the HVX version to be the same as the CPU version.
The current implementation upstream would use the most recent versioned
-mhvx= flag first (if present), then the CPU version. Change the upstream
behavior to match the documented behavior of the downstream compiler.

(cherry picked from commit 2ecda9ec)