Issue: https://github.com/llvm/llvm-project/issues/69270

These atomic primitives are required in order to implement the race
variants of the new And and Or operators in Go's sync/atomic package.
See Github issue golang/go#61395.

This caused linker issues on a buildbot:
https://lab.llvm.org/buildbot/#/builders/61/builds/50716.

This reverts commit 3c07a216.

MSVC has a major performance regression observed when targeting ARM64
since v19.32 (VS 17.2.0). `cl.exe` spends a lot of time on compiling
`StandardLibrary.cpp` and `CGBuiltin.cpp`, and total build duration
rises extremely. This makes builds stagnate even on a real hardware, but
VM-based builds (like building on cloud agents from GitHub Actions and
Azure Pipelines) are experiencing most damage as they also performance-
and time-limited.

The issue appears to be related to some optimizations applied in `/O2`
mode. It is reported on [Developer
Community](https://developercommunity.visualstudio.com/t/Compiling-a-specific-code-for-ARM64-with/10444970).
While the investigation is in progress, we could apply a workaround to
improve build time. `/O2` actually enables a set of optimizations, and
only one of them does all slowdown. The idea is to disable
optimizations, and then apply all but one back, effectively excluding
the problematic option from the set.

This patch alters the CMake configuration for aforementioned files.
Changes are limited to:
- non-debug builds
- MSVC of the specific version
- target arch (ARM64).

This was reverted in commit 0abaf3ca
(#67178).

This version of the patch includes a fix which was caused by
vp-reductions having an extra start value argument which the non-vp
counterparts did not have.

Reapplication of 7339c0f7 with a fix
for a crash involving arrays without a size expression.

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

This PR adds options to let CMake calculate the ninja job pools
depending on free memory and available cores.
You can provide memory requirements for each compile and link job which
is checked against CMake AVAILABLE_PHYSICAL_MEMORY and
NUMBER_OF_LOGICAL_CORES. [This information are available since CMake
3.0](https://cmake.org/cmake/help/v3.0/command/cmake_host_system_information.html).

This is very helpful in CI environments with multiple jobs per
environment or a VM with multiple users.
Its different to LLVM_PARALLEL_LINK_JOBS / LLVM_PARALLEL_COMPILE_JOBS
(or ninja -j 1) because it tries to use the resources more efficient
without being terminated. Only downside currently is that compile and
link jobs can run at the same time so there is an offset for link job
memory suggested which is added to the documentation.

The definitions aren't added as cache because if I understand it
correctly this would break it because values could be outdated.

"--sysroot"
should be 
"--sysroot="

since it's related to
OPT_sysroot_EQ
and not a
OPT_sysroot

[Clang][OpenMP] Check if value is contained in array, not if it's contained in the first element (#69462)

This change adds the PLATFORM XMACRO to simplify the addition of new MachO
platforms and reduce the number of required changes. Many of the changes needed
for adding a new platform are mechanical, such as adding new cases to a switch
statement. This will help streamline the process by consolidating much of the
necessary information into the MachO.def file.

This prevents redefinition errors due to having multiple paths for the
same module map. (rdar://24116019)

Originally implemented and tested downstream by @bcardosolopes, I just
made use of `FileEntryRef::getNameAsRequested()`.

This reverts commit ed83797f.

Reverting pending the investigation of https://github.com/llvm/llvm-project/issues/69658

This reverts commit e6e90840.

This is to fix https://github.com/llvm/llvm-project/issues/69697.

Shift the `determinant()` function from LinearTransform to Matrix.
Implement a FracMatrix class, inheriting from Matrix<Fraction>, for inverses.
Implement inverse for FracMatrix and intInverse for IntMatrix.
Make Matrix internals protected instead of private so that Int/FracMatrix can access them.

Without this patch, the functions `executeScriptInternal` and thus
`runOnce` in `llvm/utils/lit/lit/TestRunner.py` return either a tuple like
`(out, err, exitCode, timeoutInfo)` or a `lit.Test.Result` object. They
return the latter only when there's a lit internal shell parse error in
a RUN line. In my opinion, a more straight-forward way to handle
exceptional cases like that is to use python exceptions.

For that purpose, this patch introduces `ScriptFatal`. Thus, this patch
changes `executeScriptInternal` to always either return the tuple or
raise the `ScriptFatal` exception. It updates `runOnce` and
`libcxx/utils/libcxx/test/format.py` to catch the exception rather than
check for the special return type.

This patch also changes `runOnce` to convert the exception to a
`Test.UNRESOLVED` result instead of `TEST.FAIL`. The former is the
proper result for such a malformed test, for which a rerun (given an
`ALLOW_RETRIES:`)...

On RISC-V, GNU as produces the following initial instruction in CIE's:

```
DW_CFA_def_cfa_register: r2
```

While I believe it is technically illegal to use this instruction
without first using a `DW_CFA_def_cfa` (since the offset is undefined),
both `readelf` and `llvm-dwarfdump` accept this and implicitly set the
offset to 0.

In BOLT, however, this triggers an assert (in `CFISnapshot::advanceTo`)
as it (correctly) believes the offset is not set. This patch fixes this
by setting the offset to 0 whenever executing `DW_CFA_def_cfa_register`
while the offset is undefined.

Note that this is probably the simplest workaround but it has a
downside: while emitting CFI start, we check if the initial instructions
are contained within `MCAsmInfo::getInitialFrameState` and omit them if
they are. This will not be true for GNU CIE's (since they differ from
LLVM's) which causes an unnecessary `DW_CFA_def_cfa_register` to be
emitted.

While...

Due to an issue when lowering from scf to spirv as there was no
conversion pass for index to spirv, we are motivated to add a conversion
pass from the Index dialect to the SPIR-V dialect. Furthermore, we add
the new conversion patterns to the scf-to-spirv conversion.

Fixes #63713

Function foldRedundantCopy records COPY instructions in CopyMIs and uses
it later. But other optimizations may delete or modify it. So before
using it we should check if the extracted instruction is existing and
still a COPY instruction.

Also add  Read only registers:
   ID_AA64FPFR0_EL1
   ID_AA64ISAR3_EL1

This is based on this documentation:
https://developer.arm.com/documentation/ddi0602/2023-09



Co-authored-by: Caroline Concatto <caroline.concatto@arm.com>

Only check if gettimeofday call succeeds.

This check detects usage of ``static_cast`` pointer to the other pointer
throght `static_cast` to `void *` in C++ code.
Fixes: #68532

This implements layout_stride for C++23 and with that completes the
implementation of the C++23 mdspan header. The feature test macro is
added, and the status pages updated.

Co-authored-by: Damien L-G <dalg24@gmail.com>

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

There are some uses of "vscode" in
`lldb/packages/Python/lldbsuite/test/tools/lldb-dap/dap_server.py` where
I'm not sure if it's referring to the adapter or VS Code itself, so
those remain.

This reverts commit 7339c0f7.

Breaks bots:
https://lab.llvm.org/buildbot/#/builders/139/builds/51875
https://lab.llvm.org/buildbot/#/builders/164/builds/45262

Clang supports VLAs in C++ as an extension, but we currently only warn
on their use when you pass -Wvla, -Wvla-extension, or -pedantic.
However, VLAs as they're expressed in C have been considered by WG21
and rejected, are easy to use accidentally to the surprise of users
(e.g., https://ddanilov.me/default-non-standard-features/), and they
have potential security implications beyond constant-size arrays
(https://wiki.sei.cmu.edu/confluence/display/c/ARR32-C.+Ensure+size+arguments+for+variable+length+arrays+are+in+a+valid+range).
C++ users should strongly consider using other functionality such as
std::vector instead.

This seems like sufficiently compelling evidence to warn users about
VLA use by default in C++ modes. This patch enables the -Wvla-extension
diagnostic group in C++ language modes by default, and adds the warning
group to -Wall in GNU++ language modes. The warning is still opt-in in
C language modes, where support for VLAs is somewhat less surprising to
users.

RFC: https://discourse.llvm.org/t/rfc-diagnosing-use-of-vlas-in-c/73109
Fixes https://github.com/llvm/llvm-project/issues/62836
Differential Revision: https://reviews.llvm.org/D156565

This reverts commit e4ea0997.

The recommit fixes a reported crash by adding a missing check to make
sure the cast recipes are only introduced when vectorizing.

Test coverage added in 3cac608f.
Original commit message:
   Update the code to create Trunc/Ext recipes directly in
    adjustRecipesForReductions instead of fixing it up later in
    fixReductions.

    This explicitly models the required conversions and also makes sure they
    are generated at the right place (instead of after the exit condition),
    hence the changes in a few tests.

Currently, the interpreter does not initialize `undef` constants of
aggregate types correctly (with respect to arrays).
The initialization of the array elements is skipped although it is valid
to directly write to them. Instructions like
`insertvalue {i32, [4 x i32]} undef, i32 1, 1, 2` therefore lead to a
crash.
This is fixed by initializing array values just as fixed-size vectors or
structs.

To allow using it in places where these may not be available.

The 16-bit instructions used in them are not available on the generic
target. This patches makes them run for GFX11.

This adds a release note for all the SME support now in LLDB and a page
where I have documented the user experience (for want of a better term)
when using SVE and SME.

This includes things like which mode transitions can or cannot be
triggered from within LLDB. I hope this will serve to A: document what
I've implemented and B: be a user's guide to these extensions.

(though it is not a design document, read the commits and code for that
sort of detail)

This reverts commit ba8565fb

.

Co-authored-by: Madhur A <madhura@nvidia.com>

https://github.com/llvm/llvm-project/pull/68999 correctly computed
conversion sequence for reversed args to a template operators. This was
a breaking change as code, previously accepted in C++17, starts to break
in C++20.

Example:
```cpp
struct P {};
template<class S> bool operator==(const P&, const S &);

struct A : public P {};
struct B : public P {};
bool check(A a, B b) { return a == b; }  // This is now ambiguous in C++20.
```

In order to minimise widespread breakages, as a clang extension, we had
previously accepted such ambiguities with a warning
(`-Wambiguous-reversed-operator`) for non-template operators. Due to the
same reasons, we extend this relaxation for template operators.

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

This patch adds "nice-to-have" feature in lit.
it prints the total number of discovered tests at the beginning. It is
covenient to see the total number of tests and avoid scrolling up to the
beginning of log.

Further, this patch also prints %ge of tests.

Reviewed By: RoboTux, jdenny-ornl

Co-authored-by: Madhur A <madhura@nvidia.com>