These were in LLVM 17 but removed from LLVM 18 due to an incorrect
extension name being used.

This restores them with new extension names that match SiFive's
downstream compiler. The extension name has been used internally for
some time. It uses XSiFive instead of XSf like the newer extensions.
`cease` did not have an internal extension name so its using the `XSf`
convention.

The spec for the instructions is here
https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf
though the extension name is not listed.

Column width in the extension printing had to be changed to accommodate
a longer extension name.

Revert "[Clang][C++23] Implement P2448R2: Relaxing some constexpr
restrictions (#77753)"

This reverts commit 99500e8c because it
causes a behavior change for std=c++20. See
https://github.com/llvm/llvm-project/pull/77753.

…check

Add an environment variable by which a user can disable the pointer
validation check in DEALLOCATE statement handling. This is not safe, but
it can help make a code work that allocates a pointer with an extended
derived type, associates its target with a pointer to one of its
ancestor types, and then deallocates that pointer.

…compilation

Allow multiple module files with the same module name to exist in one
compilation; distinct modules are distinguished by their hashes.

Fixing

```
CMake Error at cmake/llvm/AddLLVM.cmake:266 (check_linker_flag):
  Unknown CMake command "check_linker_flag".
```

https://github.com/llvm/llvm-project/pull/78593 changed expression
semantics to always include the names of parent components that were
necessary to access an inherited component. This turns out to have
broken calls to inherited NOPASS procedure bindings. Update the patch to
omit explicit parent components when accessing bindings, while retaining
them for component accesses (including procedure components).

Various behavior around creating affinity masks and detecting uniform
topology depends on the topology being sorted.

resort topology after adding processor group layer to ensure that the
updated topology reflects the newly added processor group info.

Observed that the topology was not sorted correctly on high core count
AMD Epyc Genoa (2 sockets, 96 cores, 2 threads) using NUMA (NPS 2+).

Correction to e2b8cc11

When a Hollerith actual argument is associated with an unlimited
polymorphic dummy argument, it's treated as if it were CHARACTER. Some
other compilers treat it as if it had been BOZ, so emit a portability
warning.

Resolves https://github.com/llvm/llvm-project/issues/83548.

Need to record casted extractelement for the externally used scalar, not
original extract instruction.

This reverts commit 8237520e to fix
a crash in https://lab.llvm.org/buildbot/#/builders/198/builds/8891.

```
AssertionError: 'main' != 'call_through_indirect_hidden'
```

This reverts commit 5a953786.

It was pointed out that this serves as documentation for the targets
where the builtin files have yet to be converted, so this should be left
in place.  Reverting!

Instead of directly annotating pexpect-based tests with
`@skipIfWindows`, we can tag them with a new `pexpect` category. We
still automatically skip windows behavior by adding `pexpect` to the
skip category list if the platform is windows, but also allow
non-Windows users to skip them by configuring cmake with
`-DLLDB_TEST_USER_ARGS=--skip-category=pexpect`

As a prerequisite, remove the restriction that `@add_test_categories`
can only apply to test cases, and we make the test runner look for
categories on both the class and the test method.

Summary:
This test is flaky on all targets I know of. We should disable it for
now so running the test suite doesn't randomly fail 50% of the time.

27ce26b0 added the new option
-fvisibility-global-new-delete=, where -fvisibility-global-new-delete=force-hidden
is equivalent to the old option -fvisibility-global-new-delete-hidden.
At the same time, the old option was deprecated.

Test for and use the new option form first; if unsupported, try 
using the old form.

This avoids warnings in the MinGW builds, if built with Clang 18 or
newer.

Need to record casted extractelement for the externally used scalar, not
original extract instruction.

If we have something like `(select (icmp ult x, 8), x, y)`, we can use
the `(icmp ult x, 8)` to help compute the knownbits of `x`.

Closes #84699

Summary:
We previously used the `LIBC_GPU_BUILD` option to control whether or not
the GPU build was enabled. This was recently replaced with a new format
that allows treating the GPU targets more directly. However, the new
format is somewhat difficult to use for people unfamiliar with the
runtimes builds, and the removal of this option somewhat broke backward
compatibility. This patch seeks to simplify enabling the GPU build by
repurposing the old enabling option and convert it to the new interface.

Unsure what the rules are here, since this is technically a `LIBC`
option living in the LLVM location.

The changeset enables lowering of `llvm.masked.compressstore(%data,
%ptr, %mask)` for RVV for fixed vector type into:
```
%0 = vcompress %data, %mask, %vl
%new_vl = vcpop %mask, %vl
vse %0, %ptr, %1, %new_vl
```
Such lowering is only possible when `%data` fits into available LMULs
and otherwise `llvm.masked.compressstore` is scalarized by
`ScalarizeMaskedMemIntrin` pass.
Even though RVV spec in the section `15.8` provide alternative sequence
for compressstore, use of `vcompress + vcpop` should be a proper
canonical form to lower `llvm.masked.compressstore`. If RISC-V target
find the sequence from `15.8` better, peephole optimization can
transform `vcompress + vcpop` into that sequence.

This reverts commit 59ff907f to fix
crash revealed in https://lab.llvm.org/buildbot/#/builders/198/builds/8881

user is in.

Reverts llvm/llvm-project#85115
The fix was already merged in
https://github.com/llvm/llvm-project/commit/79cd2c0bb9acb4685094d6b3bf21c758aa51d3df

One or two of the tests need slight tweaks to make them pass when
building with musl.

rdar://118885724

Reverts llvm/llvm-project#82457

The bot is broken, likely because of mid-air collision.

I was trying to debug why `ninja check-compiler-rt` was taking so long
to run on my system and after some debugging it turned out that most of
the time was being spent generating core dumps.

On many current Linux systems, coredumps are no longer dumped in the CWD
but instead piped to a utility such as systemd-coredumpd that stores
them in a deterministic location. This can be done by setting the
kernel.core_pattern sysctl to start with a '|'. However, when using such
a setup the kernel ignores a coredump limit of 0 (since there is no file
being written) and we can end up piping many gigabytes of data to
systemd-coredumpd which causes the test suite to freeze for a long time.
While most piped coredump handlers do respect the crashing processes'
RLIMIT_CORE, this is notable not the case for Debian's systemd-coredump
due to a local patch that changes sysctl.d/50-coredump.conf to ignore
the specified limit and instead use RLIM_INFINITY
(https://salsa.debian.org/systemd-team/systemd/-/commit/64599ffe44f0d).

Fortunately there is a workaround: the kernel recognizes the magic value
of 1 for RLIMIT_CORE to disable coredumps when piping. One byte is also
too small to generate any coredump, so it effectively behaves as if we
had set the value to zero.

The alternative to using RLIMIT_CORE=1 would be to use prctl() with the
PR_SET_DUMPABLE flag, however that also prevents ptrace(), so makes it
impossible to attach a debugger.

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

Reviewed By: vitalybuka

Pull Request: https://github.com/llvm/llvm-project/pull/83701

All these unit tests already include ${COMPILER_RT_GTEST_SOURCE} as an
input source file and the target llvm_gtest does not exist for
standalone builds. Currently the DEPS argument is ignored for standalone
builds so the missing target is not a problem, but as part of fixing a
build race for standalone builds I am planning to include those
dependencies in COMPILER_RT_TEST_STANDALONE_BUILD_LIBS configurations.

Reviewed By: vitalybuka

Pull Request: https://github.com/llvm/llvm-project/pull/83649

[clang][modules] giving the __stddef_ headers their own modules can cause redeclaration errors with -fbuiltin-headers-in-system-modules (#84127)

On Apple platforms, some of the stddef.h types are also declared in
system headers. In particular NULL has a conflicting declaration in
<sys/_types/_null.h>. When that's in a different module from
<__stddef_null.h>, redeclaration errors can occur.

Make the \_\_stddef_ headers be non-modular in
-fbuiltin-headers-in-system-modules and restore them back to not
respecting their header guards. Still define the header guards though.
__stddef_max_align_t.h was in _Builtin_stddef_max_align_t prior to the
addition of _Builtin_stddef, and it needs to stay in a module because
struct's can't be type merged. __stddef_wint_t.h didn't used to have a
module, but leave it in it current module since it doesn't really belong
to stddef.h.

minbitwidth analysis.

Fixes test failures on AIX after #82898.

This is needed for llvm-mca to correctly apply vsetvli instruments to
these instructions.

Fixes #84799.

[Clang][Sema] Properly get captured 'this' pointer in lambdas with an explicit object parameter in constant evaluator (#81102)

There were some bugs wrt explicit object parameters in lambdas in the
constant evaluator:
- The code evaluating a `CXXThisExpr` wasn’t checking for explicit
object parameters at all and thus assumed that there was no `this` in
the current context because the lambda didn’t have one, even though we
were in a member function and had captured its `this`.
- The code retrieving captures as lvalues *did* account for explicit
object parameters, but it did not handle the case of the explicit object
parameter being passed by value rather than by reference.

This fixes #80997.

---------

Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>

See #81967

Loop guards that apply to loop SCEV bounds allow IRCE for cases with
compound loop bounds such as:

if (K > 0 && M > 0)
  for (i = 0; i < min(K, M); i++) {...}

if (K > 0 && M > 0)
  for (i = min(K, M); i >= 0; i--) {...}

Otherwise SCEV couldn't prove that loops have safe bounds in these
cases.

Co-authored-by: Aleksander Popov <apopov@azul.com>