Created using spr 1.3.4

https://reviews.llvm.org/D122407 added a static link against
libclang_rt.asan_static whenever ASAN is linked, but ignored the
-fno-sanitize-link-runtime flag. Every other conditional in
collectSanitizerRuntimes is already checking for SanArgs.linkRuntimes(),
move it to the top of the function so that newly added conditionals
don't need to remember to check it.

Move the implementation of raw_socket_stream from raw_ostream.h/cpp to
raw_socket_stream.h/cpp as requested in #73603.

If a sanitizer suppression file can not be parsed, add the supported
suppression types to the error message.

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

.

---------

Co-authored-by: Vitaly Buka <vitalybuka@gmail.com>

> Add support for reading binary Mach-o dynamic libraries. It uses
libObject APIs for extracting information relevant to TAPI and tbd
files. This includes but is not limited to load commands encode data
like install names, current/compat versions, and symbols.

This originally broke because DylibReader uses Object and Object depends
on TextAPI. Breaking this up in a nested library prevents this cycle.

This makes these variable names consisent with the capitalization
used in RISCVFeatures.td.

    The legalFor check did not work as expected. Use legalIf instead. Also
    do some simplification by removing IdxZeroTy and IdxOneTy.

There are many issues that popped up with the counted_by feature. The
patch #73730 has grown too large and approval is blocking Linux testing.

Includes reverts of:
commit 769bc11f ("[Clang] Implement the 'counted_by' attribute
(#68750)")
commit bc09ec69 ("[CodeGen] Revamp counted_by calculations
(#70606)")
commit 1a09cfb2 ("[Clang] counted_by attr can apply only to C99
flexible array members (#72347)")
commit a76adfb9 ("[NFC][Clang] Refactor code to calculate flexible
array member size (#72790)")
commit d8447c78 ("[Clang] Correct handling of negative and
out-of-bounds indices (#71877)")
Partial commit b31cd07d ("[Clang] Regenerate test checks (NFC)")

Closes #73168
Closes #75173

Many systems (glibc<2.30, Bionic before 2019, musl, macOS, etc) do not have the function.

The number of vector elements considered 'small' enough to extract is
parameterized.                                                   
                                                                 
This is to avoid going into specialized reduction lowering when a
single/couple of arith ops can do. Targets without dedicated reduction  
intrinsics can use that as an emulation path too.                  
                                                                   
Depends on https://github.com/llvm/llvm-project/pull/75846.

Propagate fast math flags.
Distinguish `minf`/`maxf` and `minimumf`/`maximumf`.

Required for future patterns in
https://github.com/llvm/llvm-project/pull/75727.

As reported in [1], it looks like the Windows headers are picky about
the order in which they are included, and the clang-format change broke
the build by reordering the headers.

[1]: https://github.com/llvm/llvm-project/pull/74334#issuecomment-1861719927

requirement, NFC.

This change does not affect functionality, just fixes the assertions in
some standard c++ library implementations.

This will result in larger atomic operations getting expanded to
`__atomic_*` libcalls via AtomicExpandPass, which matches what Clang
already does in the frontend.

While AMDGPU currently disables the use of all libcalls, I've changed it
to instead disable all of them _except_ the atomic ones. Those are
already be emitted by the Clang frontend, and enabling them in the
backend allows the same behavior there.

A displacement is an 8-, 16-, or 32-bit value.
LLVM integrated assembler silently encodes an out-of-range displacement.

GNU assembler checks the displacement and may report a warning or error
(error is for 64-bit addressing, done as part of
https://sourceware.org/PR10636).
```
movq 0x80000000(%rip), %rax
Error: 0x80000000 out of range of signed 32bit displacement

movq -0x080000001(%rax), %rax
Error: 0xffffffff7fffffff out of range of signed 32bit displacement

movl 0x100000001(%eax), %eax
Warning: 0x100000001 shortened to 0x1
```

For 32-bit addressing, GNU assembler gives no diagnostic when the
displacement is within `[-2**32,2**32)`. 16-bit addressing is similar.
```
movl 0xffffffff(%eax), %eax  # no diagnostic
movl -0xffffffff(%eax), %eax # no diagnostic
```

Supporting a larger range is probably because wraparound using a large
constant is more reasonable. E.g. Linux kernel arch/x86/kernel/head_32.S
has `leal -__PAGE_OFFSET(%ecx),%esp` where `__PAGE_OFFSET` is
0xc0000000.

This patch implements a similar behavior.

Fix #57086: when ASAN_SHADOW_OFFSET_CONST >= 0x80000000 (FreeBSD,
NetBSD, etc), `movsbl ASAN_SHADOW_OFFSET_CONST(%r10),%r10d` has an
invalid displacement (not representable as a signed 32-bit integer),
which will be diagnosed by GNU assembler.

```
% cat a.s
movsbl 0x80000000(%r10),%r10d
% as a.s
a.s: Assembler messages:
a.s:1: Error: 0x80000000 out of range of signed 32bit displacement
% clang -c a.s
```

The integrated assembler after #75747 will diagnose the invalid
displacement as well.
```
% clang -c a.s
a.s:1:19: error: displacement 2147483648 is not within [-2147483648, 2147483647]
movsbl 0x80000000(%r10),%r10d
                  ^
```

If ASAN_SHADOW_OFFSET_CONST cannot be encoded as a displacement, switch
to `movabsq+movsbl`.

The function `pthread_mutex_clocklock` is not supported by TSAN yet,
which is mentioned by[
llvm/llvm-project/issues/62623](https://github.com/llvm/llvm-project/issues/62623#issue-1701600538).
This patch is to handle this function.

Since FatLTO now uses the UnifiedLTO pipeline, we should not set the
ThinLTO module flag to true, since it may cause an assertion failure.
See https://github.com/llvm/llvm-project/issues/70703 for context.

This is follow up for https://github.com/llvm/llvm-project/pull/71902.
The
default option --continue-on-cu-index-overflow returned an error
--continue-on-cu-index-overflow: missing argument. Changed it so that it
is the
same behavior as other flags like -gsplit-dwarf. Where
--continue-on-cu-index-overflow will default to continue, and user can
set mode
with --continue-on-cu-index-overflow=\<value>.

Currently, when libc++'s views::take specially handles an iota_view, the
addition is done after dereferencing the beginning iterator. However, in
[range.take.overview]/2.3, the addition is done before the dereferencing,
which means that the standard requires the returned iota_view to have
the same W and Bound type in such cases.

This patch fixes that, and also fixes a test that was testing the 
incorrect behavior.

Fixes #75611

This reverts commit 58a2c4e2 to fix the
issue detected by https://lab.llvm.org/buildbot/#/builders/233/builds/5424.

This is a followup to d01be3c6.

This patch lifts aux vector related definitions to app.h. Because
startup's refactoring is in progress, this patch still contains
duplicated changes. This problem will be addressed very soon in an
incoming patch.

The function was using the default version of ValueObject::Dump, which
has a default of using the synthetic-ness of the top-level value for
determining whether to print _all_ values as synthetic. This resulted in
some unusual behavior, where e.g. a std::vector is stringified as
synthetic if its dumped as the top level object, but in its raw form if
it is a member of a struct without a pretty printer.

The SBValue class already has properties which determine whether one
should be looking at the synthetic view of the object (and also whether
to use dynamic types), so it seems more natural to use that.

The existing code incorrectly assumes that `Path` can be empty. It
can't, it always contains at least `<` or `"`. On Unix, this patch fixes
an incorrect diagnostics that instead of `"/Users/blah"` suggested
`"Userss/blah"`. In assert builds, this would outright crash.

This patch also fixes a bug on Windows that would prevent the diagnostic
being triggered due to separator mismatch.

rdar://91172342

- G_MERGE_VALUES and G_UNMERGE_VALUES need type pairs instead of type.

`V` was unused, and all the other deletions follow from that
observation.

This patch runs clang-format on all of libcxx/include and libcxx/src, in
accordance with the RFC discussed at [1]. Follow-up patches will format
the benchmarks, the test suite and remaining parts of the code. I'm
splitting this one into its own patch so the diff is a bit easier to
review.

This patch was generated with:

   find libcxx/include libcxx/src -type f \
      | grep -v 'module.modulemap.in' \
      | grep -v 'CMakeLists.txt' \
      | grep -v 'README.txt' \
      | grep -v 'libcxx.imp' \
      | grep -v '__config_site.in' \
      | xargs clang-format -i

A Git merge driver is available in libcxx/utils/clang-format-merge-driver.sh
to help resolve merge and rebase issues across these formatting changes.

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

1) It was marked as volatile. This is not needed and the only reason
   it was done is because it is both load and store and handled
   together with atomics. Global load to LDS was marked as volatile
   just because buffer load was done that way.
2) Preserve at least LDS (store) pointer which we always have with
   the intrinsics.
3) Use PoisonValue instead of nullptr for load memop as a Value.

SIInstrInfo::areMemAccessesTriviallyDisjoint does a DS offset checks,
but does not account for LDS DMA instructions. Added these checks.
Without it code falls through and returns true which is wrong. As a
result mayAlias would always return false for LDS DMA and a regular LDS
instruction or 2 LDS DMA instructions.

At the moment this is NFCI because we do not use this AA in a context
which may touch LDS DMA instructions. This is also unreacheable now
because of the ordered memory ref checks just above in the function and
LDS DMA is marked as volatile. This volatile marking is removed in PR
#75247, therefore I'd submit this check before #75247.

Rather than shepherding a type name all the way to the backend as a
string and attempting to parse it, get the element type out of the AST
and store that in the resource annotation metadata directly.

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

Add a sub diagnostic group under `-Wunsafe-buffer-usage` controlled by
`-Wunsafe-buffer-usage-in-container`. The subgroup will include warnings
on misuses of `std::span`, `std::vector`, and `std::array`.

Profiling cmake shows that a significant time configuring `libc` folder
is spent on running `get_object_files_for_test` in the `test` folder (13
sec in `libc/test` folder / 16 sec in `libc` folder). By caching all
needed objects for each target instead of resolving every time, the time
cmake spends on configuring `libc/test` folder is reduced to ~1s.