Depends on D152134.

This is the 2nd commit of the patch-set.

This patch makes the unit-stride segment store intrinsics to use tuple
types.

Reviewed By: rogfer01

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

Depends on D152079.

This patch-set aims to replace the existing segment load/store
intrinsics with tuple-type segment load/store intrinsics. That is, we
are removing in the segment load/store intrinsics.

This is the 1st commit of the patch-set.

This patch makes the unit-stride segment load intrinsics and
unit-stride fault-first segment load intrinsics to use tuple
types.

Reviewed By: rogfer01

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

Revert "Reland "[DebugMetadata][DwarfDebug] Fix DWARF emisson of function-local imported entities (3/7)""

This reverts commit fcc39816,
since Bitcode-upgrading code doesn't seem to be deterministic.

The left/right shift linker script operators may trigger UB.
E.g. in linkerscript/end-overflow-check.test, the initial REGION1__PADDED_SR_SHIFT is
uint64_t(-3), cause the following expression to trigger an out-of-range shift in
a ubsan build of lld.

    REGION1__PADDED_SR_SIZE = MAX(1 << REGION1__PADDED_SR_SHIFT, 32);

Protect such UBs by making RHS less than 64.

Reviewed By: aartbik

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

When D152728 hoisted the code to a helper function, it moved the call
to the helper outside of `foldICmpEquality`, so an equality check is
needed in the helper.

Reviewed By: nikic, fhahn

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

Revert "[SelectionDAG][RISCV] Add very basic PromoteIntegerResult/Op support for VP_SIGN/ZERO_EXTEND."

This reverts commit 6bf79fb0.

Reason: causes Clang to crash during Chrome debug builds: https://crbug.com/1455144

This updates the definition for ExplicitSpecifier and
DeclarationNameExtra.

The MLIR LSP server initially had plans to support running passes from the
client, but this was never implemented. The doc unnecessarily advise to
register passes and makes reference to LSP server having some interaction
with passes.

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

The first test, dwarf5-macho.test checks to make sure that dsymutil
generates the correct headers and sections for a macho binary with
DWARF v5 in it.

The second test, dwarf5-dwarf4-combination-macho.test checks that
dsymutil generates the correct headers and sections for a macho binary
with which was linked with one object file with DWARF v4 and the other
with DWARF v5 in it.

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

The current implementation was ignoring the possibility of collisions.

Differential Revision: D152586

As of Xcode 15 there is now a tool ID for LLD, likely driven by Apple's
tests with using LLD for their CAS work in clang. This updates LLD to
use the correct ID, and updates the object library so that llvm-objdump
prints it correctly.

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

Committed a slightly older patch without the proper link to the review.

This reverts commit 42874f66.

The current implementation was ignoring the possibility of collisions.

Run split-dwarf-local-impor3.ll only on x86_64-linux.

The patch is based on D144994.

D151030 added the module definitions for the module std.
This patch wires in the module and enables the basic testing.

Some notable features are missing:
- There is no test that libc++ can be fully imported as a module.
- This lacks the parts for the std.compat module.
- The module is not shipped with libc++.

Implements parts of
- P2465R3 Standard Library Modules std and std.compat

Reviewed By: ldionne, aaronmondal, #libc

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

There are some minor fixes in the definiton and it is synced with
upstream changes.

This has been reviewed as part of D151814.

This reverts commit d80fdc6f.
split-dwarf-local-impor3.ll fails because of an issue with
Dwo sections emission on Windows platform.

The GPU port of the LLVM C library needs to export a few extensions to
the interface such that users can interface with it. This patch adds the
necessary logic to define a GPU extension. Currently, this only exports
a `rpc_reset_client` function. This allows us to use the server in
D147054 to set up the RPC interface outside of `libc`.

Depends on https://reviews.llvm.org/D147054

Reviewed By: sivachandra

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

This patch begins providing a generic static library that wraps around
the raw `rpc.h` interface. As discussed in the corresponding RFC,
https://discourse.llvm.org/t/rfc-libc-exporting-the-rpc-interface-for-the-gpu-libc/71030,
we want to begin exporting RPC services to external users. In order to
do this we decided to not expose the `rpc.h` header by wrapping around
its functionality. This is done with a C-interface as we make heavy use
of callbacks and allows us to provide a predictable interface.

Reviewed By: JonChesterfield, sivachandra

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

[libc++] Merge _LIBCPP_FUNC_VIS, _LIBCPP_TYPE_VIS and _LIBCPP_EXCEPTION_ABI into _LIBCPP_EXPORTED_FROM_ABI

These macros are always defined identically, so we can simplify the code a bit by merging them.

Reviewed By: ldionne, #libc

Spies: libcxx-commits, krytarowski, smeenai

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

That is not necessary to test what we're testing, and in fact including
abort_message.cpp into that file caused some link errors if we didn't
link some of the dependencies of libc++abi directly into the test.

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

Address @v01dXYZ's comments, thanks!

This reland 5d54213e with fixes.

Testing libc++ with CMake 3.27.0-rc1 fails. It seems some of the modules
used in CMake are not included.

The error before this change was
```
CMake Error at <mono-repo>/llvm/cmake/modules/HandleLLVMOptions.cmake:821 (CHECK_C_SOURCE_COMPILES):
  Unknown CMake command "CHECK_C_SOURCE_COMPILES".
Call Stack (most recent call first):
  CMakeLists.txt:156 (include)
```

Reviewed By: thesamesam

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

libcxxrt is only used on FreeBSD and the FreeBSD CMake cache already
sets LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS to ON, as it should. This
avoids defining LIBCXX_ENABLE_NEW_DELETE_DEFINITIONS redundantly in
a place where it doesn't belong.

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

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544



Fixed PR51501 (tests from D112337).

1. Reuse of DISubprogram's 'retainedNodes' to track other function-local
   entities together with local variables and labels (this patch cares about
   function-local import while D144006 and D144008 use the same approach for
   local types and static variables). So, effectively this patch moves ownership
   of tracking local import from DICompileUnit's 'imports' field to DISubprogram's
   'retainedNodes' and adjusts DWARF emitter for the new layout. The old layout
   is considered unsupported (DwarfDebug would assert on such debug metadata).

   DICompileUnit's 'imports' field is supposed to track global imported
   declarations as it does before.

   This addresses various FIXMEs and simplifies the next part of the patch.

2. Postpone emission of function-local imported entities from
   `DwarfDebug::endFunctionImpl()` to `DwarfDebug::endModule()`.
   While in `DwarfDebug::endFunctionImpl()` we do not have all the
   information about a parent subprogram or a referring subprogram
   (whether a subprogram inlined or not), so we can't guarantee we emit
   an imported entity correctly and place it in a proper subprogram tree.
   So now, we just gather needed details about the import itself and its
   parent entity (either a Subprogram or a LexicalBlock) during
   processing in `DwarfDebug::endFunctionImpl()`, but all the real work is
   done in `DwarfDebug::endModule()` when we have all the required
   information to make proper emission.

Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>

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

This reduces the difference between libc++'s new.cpp and libc++abi's
stdlib_new_delete.cpp files, which are essentially copies of each other.

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

This reverts commit ed578f02.

Tests llvm/test/DebugInfo/Generic/split-dwarf-local-import*.ll fail
when x86_64 target is not registered.

These functions were previously removed due to problems running the
tests with `errno` in them. This was resolved previously by making the
internal implementation of these functions use a global `errno` so that
tests can still use `errno` functionality as long as they are run with a
single thread. This allows us to re-enable these tests as a previous
patch has also resolved the issue where the `stdlib` tests could not be
hermetic due to the dependence on system rounding functions.

Reviewed By: lntue

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

RFC https://discourse.llvm.org/t/rfc-dwarfdebug-fix-and-improve-handling-imported-entities-types-and-static-local-in-subprogram-and-lexical-block-scopes/68544



Fixed PR51501 (tests from D112337).

1. Reuse of DISubprogram's 'retainedNodes' to track other function-local
   entities together with local variables and labels (this patch cares about
   function-local import while D144006 and D144008 use the same approach for
   local types and static variables). So, effectively this patch moves ownership
   of tracking local import from DICompileUnit's 'imports' field to DISubprogram's
   'retainedNodes' and adjusts DWARF emitter for the new layout. The old layout
   is considered unsupported (DwarfDebug would assert on such debug metadata).

   DICompileUnit's 'imports' field is supposed to track global imported
   declarations as it does before.

   This addresses various FIXMEs and simplifies the next part of the patch.

2. Postpone emission of function-local imported entities from
   `DwarfDebug::endFunctionImpl()` to `DwarfDebug::endModule()`.
   While in `DwarfDebug::endFunctionImpl()` we do not have all the
   information about a parent subprogram or a referring subprogram
   (whether a subprogram inlined or not), so we can't guarantee we emit
   an imported entity correctly and place it in a proper subprogram tree.
   So now, we just gather needed details about the import itself and its
   parent entity (either a Subprogram or a LexicalBlock) during
   processing in `DwarfDebug::endFunctionImpl()`, but all the real work is
   done in `DwarfDebug::endModule()` when we have all the required
   information to make proper emission.

Authored-by: Kristina Bessonova <kbessonova@accesssoftek.com>

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

Replace the legacy legalizer versions - just use raw type sizes for now, we can add type specific handling if/when we need it

Fixes #63105