The test cases of mincore require getting correct page size from OS. As
`sysconf` is not functioning correctly, these patches are implemented in
a somewhat confusing way. We revert such patches and will reintroduce
mincore after we correct sysconf.

This reverts 54878b80, 985c0d19 and 418a3a45.

In preparation for the moment when we'll clang-format the whole code
base, this patch adds a script that can be used to rebase patches across
clang-format changes mechanically, without requiring manual
intervention.

See https://discourse.llvm.org/t/rfc-clang-formatting-all-of-libc-once-and-for-all.

This is in preparation for clang-formatting the whole code base. These
annotations are required either to avoid clang-format bugs or because
the manually formatted code is significantly more readable than the
clang-formatted alternative. All in all, it seems like very few
annotations are required, which means that clang-format is doing a very
good job in most cases.

Tests for support for the disjoint flag added in #72583.

As [scottmcm
described](https://discourse.llvm.org/t/conv-c-and-conv-preservemost-mix-badly-on-windows-x64/73054),
the `preserve_most` calling convention, as currently implemented, is a
bad fit for Windows on x64. The intent of `preserve_most` is "to make
the code in the caller as unintrusive as possible", but `preserve_most`
causes the caller to spill and restore ten SIMD registers. It would be
preferable to make `preserve_most` treat the XMM registers however the C
calling convention does on the target operating system.

This is a breaking change, but the documentation indicates that
`preserve_most` is still experimental, so I believe that ABI
compatibility is not yet a requirement.

I've plumbed the LLVM DebugInfoD client into LLDB, and added automatic
downloading of DWP files to the SymbolFileDWARF.cpp plugin. If you have
DEBUGINFOD_URLS set to a space delimited set of web servers, LLDB will
try to use them as a last resort when searching for DWP files. If you do
*not* have that environment variable set, nothing should be changed.
There's also a setting, per @clayborg 's suggestion, that will override
the environment variable, or can be used instead of the environment
variable. The setting is why I also needed to add an API to the
llvm-debuginfod library

### Test Plan:

Suggestions are welcome here. I should probably have some positive and
negative tests, but I wanted to get the diff up for people who have a
clue what they're doing to rip it to pieces before spending too much
time validating the initial implementation.

---------

Co-authored-by: Kevin Frei <freik@meta.com>
Co-authored-by: Alex Langford <nirvashtzero@gmail.com>

This reverts commit 60665309.

Post submit buildbots are now red. We can use these explicit errors to better
clean up existing warnings, then reland this.

Link: #73966

This will allow us to isolate the EABI from D70401 to this new function.

This ensures we clip the index to be in bounds of the vector we are
inserting into. If the index is out of bounds the results of the insert
element is poison. If we don't clip the index we can write memory that
was not part of the original store.

Fixes #74248.

Reviewers: zacklj89

Reviewed By: zacklj89

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

A recent commit introduced warnings observable when building unit tests.
If the
unit tests don't fail when warnings are introduced into the build, then
we
might fail to notice them in the stream of output from check-libc.

Link: https://github.com/llvm/llvm-project/pull/72763/files#r1410932348

math_extras.h is used in integer_utils.h when building for 32-bit
platforms but the include is missing.

Set BufferSize=0 and remove Super pipes for these resources.

Update all callers to pass through the Address.

For the older builtins such as `__sync_*` and MSVC `_Interlocked*`,
natural alignment of the atomic access is _assumed_. This change
preserves that behavior. It will pass through greater-than-required
alignments, however.

This PR unifies the startup library's code style with the rest of libc.

This is part of a stack of PRs to add support for symbolizer
markup in linux.

Render contextual symbolizer markup elements. For Fuchsia it is not
necessary to emit any context given that Fuchsia's logging
infrastructure already handles emitting it when necessary.

For more information about contextual symbolizer markup elements:
https://llvm.org/docs/SymbolizerMarkupFormat.html#contextual-elements

Reviewers: PiJoules, petrhosek, vitalybuka

Reviewed By: petrhosek, vitalybuka

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

With the combination of an early return and removing an else-after-return, it
becomes evident that there is unreachable code in the function being changed.

This will enable us to prove that there is unreachable code in this function in
a subsequent commit.

The existing code was taking three substrings from a regex match and converting
to std::strings prior to using them. This may have been done to address
null-termination concerns, but this is not the case:

1. `name` was being used to call `c_str()` and then implicitly converted back to
a `StringRef` on the call to `ToAddress`. While the path `const char *` ->
`StringRef` requires null-termination, we can simply use the original StringRef.
2. `str_offset` was being converted back to a StringRef in order to call a
member method. Member methods can't handle non-null termination.
3. `sign` simply had it's 0-th element accessed.

These test cases fail when the libcxx and libcxxabi runtimes are
built on Linux PowerPC. XFailing them until the issue is resolved.

This commit fixes a compilation warning caused by the printExpressionArg
function that previously returned LogicalResult instead of void.

The warning has been introduced by #73367.

Add:
* an Op for 'cp.async.mbarrier.arrive', targeting the
nvvm_cp_async_mbarrier_arrive* family of intrinsics.
* The 'noinc' intrinsic property is modelled as a default-valued-attr of
type I1.
* Test cases are added to verify the Op as well as the intrinsic
lowering.

Signed-off-by: Durgadoss R <durgadossr@nvidia.com>

Implement a selection of intrinsic module procedures that involve
exceptions.

 - IEEE_GET_FLAG
 - IEEE_GET_HALTING_MODE
 - IEEE_GET_MODES
 - IEEE_GET_STATUS
 - IEEE_LOGB
 - [f23] IEEE_MAX, IEEE_MAX_MAG, IEEE_MAX_NUM, IEEE_MAX_NUM_MAG
 - [f23] IEEE_MIN, IEEE_MIN_MAG, IEEE_MIN_NUM, IEEE_MIN_NUM_MAG
 - IEEE_QUIET_EQ, IEEE_QUIET_GE, IEEE_QUIET_GT,
 - IEEE_QUIET_LE, IEEE_QUIET_LT, IEEE_QUIET_NE
 - IEEE_SET_FLAG
 - IEEE_SET_HALTING_MODE
 - IEEE_SET_MODES
 - IEEE_SET_STATUS
 - IEEE_SIGNALING_EQ, IEEE_SIGNALING_GE, IEEE_SIGNALING_GT,
 - IEEE_SIGNALING_LE, IEEE_SIGNALING_LT, IEEE_SIGNALING_NE
 - IEEE_SUPPORT_FLAG
 - IEEE_SUPPORT_HALTING

Add spirv-dis (disassembler) and spirv-val (validator) from SPIRV-Tools
as external dependencies for testing the SPIR-V backend. These tools are
test dependencies only.

SPIR-V backend tests now have a dependency on the spirv-dis and
spirv-val targets when the `LLVM_INCLUDE_SPIRV_TOOLS_TESTS` cmake
variable is set, which allows additional test files with the `REQUIRES:
spirv-tools` constraint to run, along with additional `RUN: %if
spirv-tools ...` lines in existing tests. All other SPIR-V backend tests
will run normally when `LLVM_INCLUDE_SPIRV_TOOLS_TESTS` is not set.

Several tests are included to show these tools' use, however more tests
will be migrated and added later.
* OpVariable_order.ll shows how spirv-val can catch bugs in the backend.
* basic_int_types_spirvdis.ll shows how tests can be much shorter and
more readable by FileChecking the spirv-dis output.
* basic_int_types.ll shows how an additional RUN line can add validation
to existing tests.

RFC:
https://discourse.llvm.org/t/rfc-add-a-test-dependency-on-spirv-tools/75135

Add definitions for
broadcast, gather, receive, reduce, scatter, send and shift.

This patch removes the ArmSMETypeConverter, and instead updates
`populateArmSMEToLLVMConversionPatterns()` to add an ArmSME vector type
conversion to the existing LLVMTypeConverter. This makes it easier to
add these patterns to an existing `-to-llvm` lowering pass.

Following the discussion here:

  * https://github.com/llvm/llvm-project/pull/72105

this patch makes the `TransposeOpLowering` configurable so that one can select
whether to favour `vector.shape_cast` over `vector.transpose`.

As per the discussion in #72105, using `vector.shape_cast` is very beneficial
and desirable when targeting `LLVM IR` (CPU lowering), but won't work when
targeting `SPIR-V` today (GPU lowering). Hence the need for a mechanism to be
able to disable/enable the pattern introduced in #72105. This patch proposes one
such mechanism.

While this should solve the problem that we are facing today, it's understood to
be a temporary workaround. It should be removed once support for lowering
`vector.shape_cast` to SPIR-V is added. Also, (once implemented) the following
proposal might make this workaround redundant:

  * https://discourse.llvm.org/t/improving-handling-of-unit-dimensions-in-the-vector-dialect/

The minimum GCC version was bumped from 7.1 to 7.4 so garbage collect
the 7.2 workarounds.

https://reviews.llvm.org/D156286

Before this PR, readability-container-contains fix-its did not handle
integer literal suffixes correctly. It e.g. changed
```
  MyMap.count(2) != 0U;
```
into
```
  MyMap.contains(2)U;
```

With this PR, it correctly changes it to
```
  MyMap.contains(2);
```

This commit extends the class `SValBuilder` with the methods
`getMinValue()` and `getMaxValue()` to that work like
`SValBuilder::getKnownValue()` but return the minimal/maximal possible
value the `SVal` is not perfectly constrained.

This extension of the ConstraintManager API is discussed at:
https://discourse.llvm.org/t/expose-the-inferred-range-information-in-warning-messages/75192

As a simple proof-of-concept application of this new API, this commit
extends a message from `core.BitwiseShift` with some range information
that reports the assumptions of the analyzer.

My main motivation for adding these methods is that I'll also want to
use them in `ArrayBoundCheckerV2` to make the error messages less
awkward, but I'm starting with this simpler and less important usecase
because I want to avoid merge conflicts with my other commit
https://github.com/llvm/llvm-project/pull/72107 which is currently under
review.

The testcase `too_large_right_operand_compound()` shows a situation
where querying the range information does not work (and the extra
information is not added to the error message). This also affects the
debug utility `clang_analyzer_value()`, so the problem isn't in the
fresh code. I'll do some investigations to resolve this, but I think
that this commit is a step forward even with this limitation.

In commit b0533598 ("[X86InstrInfo] support memfold on spillable
inline asm
(#70832)"), I had a last minute fix to update the memoperands. I
originally
did this in the parent foldInlineAsmMemOperand call, updated the mir
test via
update_mir_test_checks.py, but then decided to move it to the child call
of
foldInlineAsmMemOperand.

But I forgot to rerun update_mir_test_checks.py. That last minute change
caused
the same memoperand to be added twice when recursion occurred (for tied
operands). I happened to get lucky that trailing content omitted from
the
CHECK line doesn't result in test failure.

But rerunning update_mir_test_checks.py on the mir test added in that
commit
produces updated output. This is resulting in updates to the test that:
1. conflate additions to the test in child commits with simply updating
the
   test as it should have been when first committed.
2. look wrong because the same memoperand is specified twice (we don't
   deduplicate memoperands when added). Example:

INLINEASM ... :: (load (s32) from %stack.0) (load (s32) from %stack.0)

Fix the bug, so that in child commits, we don't have additional
unrelated test
changes (which would be wrong anyways) from simply running
update_mir_test_checks.py.

Link: #20571

Fixes #41439

The documentation is update to say it is allowed to have omitted
parameter names if the variable is not used

Most addresses in SystemZ instructions take two registers,
an index register and a base register.  However, either of
those can be omitted.  If there is just a single register,
this usually is taken as the base register - however, there
are certain rare cases where you specifically want to use
an index register but no base register.  This is currently
not handled consistently by the assembler / disassembler.

Fix this by
 - always emitting a dummy 0 as base register for index-
   only addresses
 - correctly handle dummy 0 as indicating no base register
   when parsing an address

This is compatible with current GNU binutils behavior.