[clang-tidy]avoid bugprone-unused-return-value false positive for assignment operator overloading (#84489)

Added --offload-compression-level= option to clang and
-compression-level=
option to clang-offload-bundler for controlling compression level.

Added support of long distance matching (LDM) for llvm::zstd which is
off
by default. Enable it for clang-offload-bundler by default since it
improves compression rate in general.

Change default compression level to 3 for zstd for clang-offload-bundler
since it works well for bundle entry size from 1KB to 32MB, which should
cover most of the clang-offload-bundler usage. Users can still specify
compression level by -compression-level= option if necessary.

llvm-project/clang/lib/Format/TokenAnnotator.cpp:2707:43:
error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]
    auto IsQualifiedPointerOrReference = [this](FormatToken *T) {
                                          ^~~~
1 error generated.

This reverts commit 2bd369b4.

That commit triggered failed assertions:
$ cat repro.c
short *a;
int b;
void h() {
  short *c = a;
  b = 0;
  for (; b < 4; b++) {
    unsigned d = a[b] + a[b + 4 * 2], e = a[b] - a[b + 4 * 2],
             f = (a[b + 4] >> 1) - a[b + 4 * 3],
             g = a[b + 4] + (a[b + 4 * 3] >> 1);
    c[b] = g;
    c[b + 4] = e + f;
    c[b + 4 * 2] = e - f;
    c[b + 4 * 3] = d - g;
  }
}
$ clang -target aarch64-linux-gnu -c -O2 repro.c
clang: ../lib/Transforms/Vectorize/SLPVectorizer.cpp:12503: llvm::Value* llvm::slpvectorizer::BoUpSLP::vectorizeTree(llvm::slpvectorizer::BoUpSLP::TreeEntry*, bool): Assertion `(MinBWs.contains(getOperandEntry(E, 0)) || MinBWs.contains(getOperandEntry(E, 1))) && "Expected item in MinBWs."' failed.

This reduces the include time of `<span>` from 122ms to 78ms.

The only change from https://github.com/llvm/llvm-project/pull/83171 is the
change of the allocator so the destructor is called for
ConstantRangeAttributeImpl.

reverts https://github.com/llvm/llvm-project/pull/84549

netbsd supports the portable hwloc's layer as well. for a hardware with
4 cpus, a cpu set is 4 and maxcpus is 256.

Fix a test that was added in #81014 and which caused buildbots to fail.
Only check for the ‘never produces a constant expression error’ in C++20
mode.

This fixes #84623.

The specifications of format had a contradiction, libc++ always
implemented the code as-if LWG3462 has been done; the contradiction was
a bit hard to spot.

Marks as nothing to do:
- LWG3462 §[formatter.requirements]: Formatter requirements forbid use
of fc.arg()

The issue has been resolved in https://reviews.llvm.org/D121138 since it
was needed to implement format. This updates the status of the LWG-issue
filed for this review.

Marks as complete:
- LWG3701 Make formatter<remove_cvref_t<const charT[N]>, charT>
requirement explicit

This implements the C++23 `[[assume]]` attribute.

Assumption information is lowered to a call to `@llvm.assume`, unless the expression has side-effects, in which case it is discarded and a warning is issued to tell the user that the assumption doesn’t do anything. A failed assumption at compile time is an error (unless we are in `MSVCCompat` mode, in which case we don’t check assumptions at compile time).

Due to performance regressions in LLVM, assumptions can be disabled with the `-fno-assumptions` flag. With it, assumptions will still be parsed and checked, but no calls to `@llvm.assume` will be emitted and assumptions will not be checked at compile time.

This fixes MSVC warning C4127: conditional expression is constant.

Testing `TEST_STD_AT_LEAST_20_OR_RUNTIME_EVALUATED` by itself doesn't
emit this warning, but the condition here is more complicated. I'm
expanding the macro and mechanically simplifying the resulting code.

(Yeah, this warning is often annoying, and I introduced
`TEST_STD_AT_LEAST_20_OR_RUNTIME_EVALUATED` to avoid this warning
elsewhere, so it's disappointing that it doesn't make the compiler happy
here. If this change is undesirable, I can replace it with
`ADDITIONAL_COMPILE_FLAGS(cl-style-warnings)`, but ideally I'd like to
avoid having to suppress it.)

---------

Co-authored-by: Louis Dionne <ldionne.2@gmail.com>

This depends on enabling extensions in the implementation.

Umbrella bug #83182

Reverts llvm/llvm-project#74110

Fails on many bots:
https://lab.llvm.org/buildbot/#/builders/5/builds/41633

LLVM is inconsistent about how it converts `errno` to `std::error_code`.
This can cause problems because values outside of `std::errc` compare
differently if one is system and one is generic on POSIX systems.

This is even more of a problem on Windows where use of the system
category is just wrong, as that is for Windows errors, which have a
completely different mapping than POSIX/generic errors. This patch fixes
one instance of this mistake in `JSONTransport.cpp`.

This patch adds `errnoAsErrorCode()` which makes it so people do not
need to think about this issue in the future. It also cleans up a lot of
usage of `errno` in LLVM and Clang.

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.

See https://github.com/llvm/llvm-project/pull/83701 and
https://github.com/llvm/llvm-project/issues/45797

Reviewed By: MaskRay

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

This can be useful because dlsym() may call malloc on failure which could
result in other interposed functions being called that could eventually
make use of TLS. While the crash that I experienced originally has been
fixed differently (by not using global-dynamic TLS accesses in the mutex
deadlock detector, see https://github.com/llvm/llvm-project/pull/83890),
moving this interception earlier is still a good since it makes the code
a bit more robust against initialization order problems.

Reviewed By: MaskRay, vitalybuka

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

TestCases/Misc/Linux/sigaction.cpp fails because dlsym() may call malloc
on failure. And then the wrapped malloc appears to access thread local
storage using global dynamic accesses, thus calling
___interceptor___tls_get_addr, before REAL(__tls_get_addr) has
been set, so we get a crash inside ___interceptor___tls_get_addr. For
example, this can happen when looking up __isoc23_scanf which might not
exist in some libcs.

Fix this by marking the thread local variable accessed inside the
debug checks as "initial-exec", which does not require __tls_get_addr.

This is probably a better alternative to https://github.com/llvm/llvm-project/pull/83886.

This fixes a different crash but is related to https://github.com/llvm/llvm-project/issues/46204.

Backtrace:
```
#0 0x0000000000000000 in ?? ()
#1 0x00007ffff6a9d89e in ___interceptor___tls_get_addr (arg=0x7ffff6b27be8) at /path/to/llvm/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:2759
#2 0x00007ffff6a46bc6 in __sanitizer::CheckedMutex::LockImpl (this=0x7ffff6b27be8, pc=140737331846066) at /path/to/llvm/compiler-rt/lib/sanitizer_common/sanitizer_mutex.cpp:218
#3 0x00007ffff6a448b2 in __sanitizer::CheckedMutex::Lock (this=0x7ffff6b27be8, this@entry=0x730000000580) at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_mutex.h:129
#4 __sanitizer::Mutex::Lock (this=0x7ffff6b27be8, this@entry=0x730000000580) at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_mutex.h:167
#5 0x00007ffff6abdbb2 in __sanitizer::GenericScopedLock<__sanitizer::Mutex>::GenericScopedLock (mu=0x730000000580, this=<optimized out>) at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_mutex.h:383
#6 __sanitizer::SizeClassAllocator64<__tsan::AP64>::GetFromAllocator (this=0x7ffff7487dc0 <__tsan::allocator_placeholder>, stat=stat@entry=0x7ffff570db68, class_id=11, chunks=chunks@entry=0x7ffff5702cc8, n_chunks=n_chunks@entry=128) at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_allocator_primary64.h:207
#7 0x00007ffff6abdaa0 in __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__tsan::AP64> >::Refill (this=<optimized out>, c=c@entry=0x7ffff5702cb8, allocator=<optimized out>, class_id=<optimized out>)
 at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_allocator_local_cache.h:103
#8 0x00007ffff6abd731 in __sanitizer::SizeClassAllocator64LocalCache<__sanitizer::SizeClassAllocator64<__tsan::AP64> >::Allocate (this=0x7ffff6b27be8, allocator=0x7ffff5702cc8, class_id=140737311157448)
 at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_allocator_local_cache.h:39
#9 0x00007ffff6abc397 in __sanitizer::CombinedAllocator<__sanitizer::SizeClassAllocator64<__tsan::AP64>, __sanitizer::LargeMmapAllocatorPtrArrayDynamic>::Allocate (this=0x7ffff5702cc8, cache=0x7ffff6b27be8, size=<optimized out>, size@entry=175, alignment=alignment@entry=16)
 at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_allocator_combined.h:69
#10 0x00007ffff6abaa6a in __tsan::user_alloc_internal (thr=0x7ffff7ebd980, pc=140737331499943, sz=sz@entry=175, align=align@entry=16, signal=true) at /path/to/llvm/compiler-rt/lib/tsan/rtl/tsan_mman.cpp:198
#11 0x00007ffff6abb0d1 in __tsan::user_alloc (thr=0x7ffff6b27be8, pc=140737331846066, sz=11, sz@entry=175) at /path/to/llvm/compiler-rt/lib/tsan/rtl/tsan_mman.cpp:223
#12 0x00007ffff6a693b5 in ___interceptor_malloc (size=175) at /path/to/llvm/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp:666
#13 0x00007ffff7fce7f2 in malloc (size=175) at ../include/rtld-malloc.h:56
#14 __GI__dl_exception_create_format (exception=exception@entry=0x7fffffffd0d0, objname=0x7ffff7fc3550 "/path/to/llvm/compiler-rt/cmake-build-all-sanitizers/lib/linux/libclang_rt.tsan-x86_64.so",
 fmt=fmt@entry=0x7ffff7ff2db9 "undefined symbol: %s%s%s") at ./elf/dl-exception.c:157
#15 0x00007ffff7fd50e8 in _dl_lookup_symbol_x (undef_name=0x7ffff6af868b "__isoc23_scanf", undef_map=<optimized out>, ref=0x7fffffffd148, symbol_scope=<optimized out>, version=<optimized out>, type_class=0, flags=2, skip_map=0x7ffff7fc35e0) at ./elf/dl-lookup.c:793
--Type <RET> for more, q to quit, c to continue without paging--
#16 0x00007ffff656d6ed in do_sym (handle=<optimized out>, name=0x7ffff6af868b "__isoc23_scanf", who=0x7ffff6a3bb84 <__interception::InterceptFunction(char const*, unsigned long*, unsigned long, unsigned long)+36>, vers=vers@entry=0x0, flags=flags@entry=2) at ./elf/dl-sym.c:146
#17 0x00007ffff656d9dd in _dl_sym (handle=<optimized out>, name=<optimized out>, who=<optimized out>) at ./elf/dl-sym.c:195
#18 0x00007ffff64a2854 in dlsym_doit (a=a@entry=0x7fffffffd3b0) at ./dlfcn/dlsym.c:40
#19 0x00007ffff7fcc489 in __GI__dl_catch_exception (exception=exception@entry=0x7fffffffd310, operate=0x7ffff64a2840 <dlsym_doit>, args=0x7fffffffd3b0) at ./elf/dl-catch.c:237
#20 0x00007ffff7fcc5af in _dl_catch_error (objname=0x7fffffffd368, errstring=0x7fffffffd370, mallocedp=0x7fffffffd367, operate=<optimized out>, args=<optimized out>) at ./elf/dl-catch.c:256
#21 0x00007ffff64a2257 in _dlerror_run (operate=operate@entry=0x7ffff64a2840 <dlsym_doit>, args=args@entry=0x7fffffffd3b0) at ./dlfcn/dlerror.c:138
#22 0x00007ffff64a28e5 in dlsym_implementation (dl_caller=<optimized out>, name=<optimized out>, handle=<optimized out>) at ./dlfcn/dlsym.c:54
#23 ___dlsym (handle=<optimized out>, name=<optimized out>) at ./dlfcn/dlsym.c:68
#24 0x00007ffff6a3bb84 in __interception::GetFuncAddr (name=0x7ffff6af868b "__isoc23_scanf", trampoline=140737311157448) at /path/to/llvm/compiler-rt/lib/interception/interception_linux.cpp:42
#25 __interception::InterceptFunction (name=0x7ffff6af868b "__isoc23_scanf", ptr_to_real=0x7ffff74850e8 <__interception::real___isoc23_scanf>, func=11, trampoline=140737311157448)
 at /path/to/llvm/compiler-rt/lib/interception/interception_linux.cpp:61
#26 0x00007ffff6a9f2d9 in InitializeCommonInterceptors () at /path/to/llvm/compiler-rt/lib/tsan/rtl/../../sanitizer_common/sanitizer_common_interceptors.inc:10315
```

Reviewed By: vitalybuka, MaskRay

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

This patch relands #67410 and fixes the cmpfail below:
#include <immintrin.h>
__attribute__((target("avx"))) void test(__m128 a, __m128 b) {
  _mm_cmp_ps(a, b, 14);
}

According to Intel SDM, SSE/SSE2 instructions cmp[p|s][s|d] are
supported when imm8 is in range of [0, 7]

We can rely on the compiler-provided macro __SIZE_TYPE__ for all
non-MSVC compilers and fall back to `uptr` otherwise.
I verified via https://godbolt.org/z/MW9KMjv5f that this works for MSVC
as well as GCC 4.5 Clang 3.0, so that should cover supported compilers.

While touching this also rename operator_new_size_type to usize which
makes it more obvious that this is the equivalent to size_t within
the sanitizers runtime (which I plan to use in follow-up changes).

Reviewed By: vitalybuka

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

After aa020024 we started passing the
user name to the create_release function and this was being interpreted
as the git tag.

Fixes #83400.

Adds `LLVMConstStringInContext2` and `LLVMConstString2`, which are
identical to originals except that they use `size_t` for length. This is
a clone of
https://github.com/llvm/llvm-project/commit/35276f16e5a2cae0dfb49c0fbf874d4d2f177acc
and is needed for https://github.com/rust-lang/rust/pull/122000.

As an aside, the issue of 32 bit overflow on constants is present in the
C++ APIs as well. A few classes, e.g. `ConstantDataArray` and
`ConstantAggregateZero`, can hold 64-bit ArrayTypes but their length
accessors return 32-bit values. This means the same issue from the
original Rust report is also present in LLVM itself. Would it be a
reasonable goal to update all of these length methods & types to be
uint64_t, or would that be too breaking? Alternatively, we could use
safe fallible casts instead of implicit ones inside the accessors (if an
overflow does happen, the solution would be to use
`MyValue->getType()->getArrayNumElements()` instead).

I messed up the syntax here previously - let's see if this is enough to
get it working.

No nans/infs in SelectionDAG is complicated. Hopefully I've captured
all of the cases. I've only applied to ConsiderFlags to the SDNodeFlags
since those are the only ones that will be droped by hoisting. The
condition code and TargetOptions would still be in effect.
    
Recovers some regression from #84232.

In valid code, there should only be a very specific set of members in a
lambda definition. If the user tries to define something inside the
lambda class, this assumption is violated and causes an assertion error.
This can be fixed by checking whether the members are valid, and if not,
ignore that the class members are potentially unexpected.

I've come across this while working on implementing lambdas in C++03.

We've talked about allowing extensions on
[discourse](https://discourse.llvm.org/t/rfc-use-language-extensions-from-future-standards-in-libc/71898/5)
and in a libc++ monthly meeting and agreed to test it out in the LLVM 18
release. We've done that with the `tuple` constructor overload set
(using conditional `explicit`). Since we haven't heard about any
breakages, it seems safe to do. This patch enables the use of extension
from later C++ standards inside the versioned `std` namespaces. This
should be good enough, since almost all of our code is inside that
namespace. This approach also avoids the use of extensions inside the
test `std` suite. That part of the code base should stay clean, since
it's a test suite that is also used by other vendors to test their
implementations.

Change GetNumChildren()/CalculateNumChildren() methods return
llvm::Expected

This is an NFC change that does not yet add any error handling or change
any code to return any errors.

This is the second big change in the patch series started with
https://github.com/llvm/llvm-project/pull/83501

A follow-up PR will wire up error handling.

…efault (#83201)"

This reverts commit 062cfada. See issue
#84574.

This patch adds a the `LowerVectorToArmNeonPattern` patterns to the
ArmNeon.

This pattern inspects `vector.contract` ops that can be 1-1 mapped to an
`arm.neon.smmla` intrinsic. The contract ops must be separated into
tiles who's inputs must fit that of a single smmla op (`2x8xi32` inputs
and `2x2xi32` output). The `vector.contract` inputs must be sign
extended from narrow types (<=i8) to be converted. If all conditions are
met, an smmla op is inserted with additional `vector.shape_casts` to
handle linearizing the input and output dimension.

Tested in AOSP.

…ning when unittest is enabled