[compiler-rt] Fix detecting _Float16 support for secondary targets (#117813)

It turns out we were not passing -m32 to the check_c_source_compiles()
invocation since CMAKE_REQUIRE_FLAGS needs to be string separated list
and
we were passing a ;-separated CMake list which appears to be parsed by
CMake as 'ignore all arguments beyond the first'.
Fix this by transforming the list to a command line first.

With this change, Clang 17 no longer claims to support _Float16 for
i386.

packaigng: bump-up version to 19.1.4

Change-Id: I118dfd02927a23ed29fa0b9809afe26158774f1a
Signed-off-by: Slava Barinov <v.barinov@samsung.com>
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>
Signed-off-by: Hyungju Lee <leee.lee@samsung.com>
Signed-off-by: Alexander Soldatov <soldatov.a@samsung.com>
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>
Signed-off-by: Hyunggi Lee <hyunggi.lee@samsung.com>

Link libclang_rt.asan.so against libatomic when necessary

To build libclang_rt.asan.so on RISC-V it is required to link it against
libatomic.

Change-Id: Iafdc20fc8ecffeeaa289e03b01267bbabdd48a9e
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>

[llvm][clang]  Add support for Tizen toolchain vendor

Port of
ebf1682d714e4b6c1487ea0e136cf7c1ec30f46d
8845ba7f79513b7e362fed80bb57b708352ddbbd

Signed-off-by: Slava Barinov <v.barinov@samsung.com>

[WebAssembly] Fix rethrow's index calculation (#114693)

So far we have assumed that we only rethrow the exception caught in the
innermost EH pad. This is true in code we directly generate, but after
inlining this may not be the case. For example, consider this code:
```ll
ehcleanup:
  %0 = cleanuppad ...
  call @destructor
  cleanupret from %0 unwind label %catch.dispatch
```

If `destructor` gets inlined into this function, the code can be like
```ll
ehcleanup:
  %0 = cleanuppad ...
  invoke @throwing_func
    to label %unreachale unwind label %catch.dispatch.i

catch.dispatch.i:
  catchswitch ... [ label %catch.start.i ]

catch.start.i:
  %1 = catchpad ...
  invoke @some_function
    to label %invoke.cont.i unwind label %terminate.i

invoke.cont.i:
  catchret from %1 to label %destructor.exit

destructor.exit:
  cleanupret from %0 unwind label %catch.dispatch
```

We lower a `cleanupret` into `rethrow`, which assumes it rethrows the
exception caught by the nearest dominating EH pad. But after the
inlining, the nearest dominating EH pad is not `ehcleanup` but
`catch.start.i`.

The problem exists in the same manner in the new (exnref) EH, because it
assumes the exception comes from the nearest EH pad and saves an exnref
from that EH pad and rethrows it (using `throw_ref`).

This problem can be fixed easily if `cleanupret` has the basic block
where its matching `cleanuppad` is. The bitcode instruction `cleanupret`
kind of has that info (it has a token from the `cleanuppad`), but that
info is lost when when we enter ISel, because `TargetSelectionDAG.td`'s
`cleanupret` node does not have any arguments:

https://github.com/llvm/llvm-project/blob/5091a359d9807db8f7d62375696f93fc34226969/llvm/include/llvm/Target/TargetSelectionDAG.td#L700
Note that `catchret` already has two basic block arguments, even though
neither of them means `catchpad`'s BB.

This PR adds the `cleanuppad`'s BB as an argument to `cleanupret` node
in ISel and uses it in the Wasm backend. Because this node is also used
in X86 backend we need to note its argument there too but nothing more
needs to change there as long as X86 doesn't need it.

---

- Details about changes in the Wasm backend:

After this PR, our pseudo `RETHROW` instruction takes a BB, which means
the EH pad whose exception it needs to rethrow. There are currently two
ways to generate a `RETHROW`: one is from `llvm.wasm.rethrow` intrinsic
and the other is from `CLEANUPRET` we discussed above. In case of
`llvm.wasm.rethrow`, we add a '0' as a placeholder argument when it is
lowered to a `RETHROW`, and change it to a BB in LateEHPrepare. As
written in the comments, this PR doesn't change how this BB is computed.
The BB argument will be converted to an immediate argument as with other
control flow instructions in CFGStackify.

In case of `CLEANUPRET`, it already has a BB argument pointing to an EH
pad, so it is just converted to a `RETHROW` with the same BB argument in
LateEHPrepare. This will also be lowered to an immediate in CFGStackify
with other control flow instructions.

---

Fixes #114600.

Reapply "[sanitizer_common] AND signals in BlockSignals instead of deleting (#113443)" for non-Android Linux only (#115790)

The original patch (25fd366d6a7d40266ff27c134ed8beb0a90cc33b) was
reverted in 083a5cdbeab09517d8345868970d4f41170d7ed2 because it broke
some buildbots.

This revised patch makes two changes:
- Reverts to *pre-#98200* behavior for Android. This avoids a build
breakage on Android.
- Only define KeepUnblocked if SANITIZER_LINUX: this avoids a build
breakage on solaris, which does not support internal_sigdelset.
N.B. Other buildbot failures were non-sanitizer tests and are therefore
unrelated.

Original commit message:
    My earlier patch https://github.com/llvm/llvm-project/pull/98200
    caused a regression because it unconditionally unblocked synchronous
    signals, even if the user program had deliberately blocked them.
    This patch fixes the issue by checking the current signal mask, as
    suggested by Vitaly. It also adds tests.
    Fixes #113385

(cherry picked from commit 531acf9e2f24977d2556b39229b22f4518a1faa5)

[MSVC] work-around for compile time issue 102513

Manual cherry-pick of #110986 to the LLVM 19 release branch.

[SystemZ] Use the EVT version of getVectorVT() in combineTruncateExtract(). (#100150)

A test case showed up where the new vector type is v24i16, which is not a simple
MVT. In order to get an extended value type for cases like this, EVT::getVectorVT()
needs to be called instead of MVT::getVectorVT(), otherwise the following call
to getVectorElementType() in combineExtract() will fail.

(cherry picked from commit 22bc9db92b46965882b1c77aebc86430149b0912)

[InstCombine] Drop nsw in negation of select (#112893)

Closes https://github.com/llvm/llvm-project/issues/112666 and
https://github.com/llvm/llvm-project/issues/114181.

(cherry picked from commit ff07df6620c32571c7e13ff96ec7976c63ed0ab8)

[libc++] Fix broken configuration system-libcxxabi on Apple (#110920)

On Apple platforms, using system-libcxxabi as an ABI library wouldn't
work because we'd try to re-export symbols from libc++abi that the
system libc++abi.dylib might not have. Instead, only re-export those
symbols when we're using the in-tree libc++abi.

This does mean that libc++.dylib won't re-export any libc++abi symbols
when building against the system libc++abi, which could be fixed in
various ways. However, the best solution really depends on the intended
use case, so this patch doesn't try to solve that problem.

As a drive-by, also improve the diagnostic message when the user forgets
to set the LIBCXX_CXX_ABI_INCLUDE_PATHS variable, which would previously
lead to a confusing error.

Closes #104672

(cherry picked from commit 21da4e7f51c7adfd0b1c5defc8bd0d16ea1ce759)

[C++20] [Modules] Fix the duplicated static initializer problem (#114193)

Reproducer:

```
//--- a.cppm
export module a;
int func();
static int a = func();

//--- a.cpp
import a;
```

The `func()` should only execute once. However, before this patch we
will somehow import `static int a` from a.cppm incorrectly and
initialize that again.

This is super bad and can introduce serious runtime behaviors.

And also surprisingly, it looks like the root cause of the problem is
simply some oversight choosing APIs.

(cherry picked from commit 259eaa6878ead1e2e7ef572a874dc3d885c1899b)

[clang] Fix C23 constexpr crashes (#112708)

Before using a constexpr variable that is not properly initialized check
that it is valid.

Fixes https://github.com/llvm/llvm-project/issues/109095
Fixes https://github.com/llvm/llvm-project/issues/112516

[llvm][aarch64] Fix Arm64EC name mangling algorithm (#115567)

Arm64EC uses a special name mangling mode that adds `$$h` between the
symbol name and its type. In MSVC's name mangling `@` is used to
separate the name and type BUT it is also used for other purposes, such
as the separator between paths in a fully qualified name.

The original algorithm was quite fragile and made assumptions that
didn't hold true for all MSVC mangled symbols, so instead of trying to
improve this algorithm we are now using the demangler to indicate where
the insertion point should be (i.e., to parse the fully-qualified name
and return the current string offset).

Also fixed `isArm64ECMangledFunctionName` to search for `@$$h` since the
`$$h` must always be after a `@`.

Fixes #115231

[InstCombine] Intersect nowrap flags between geps while folding into phi

A miscompilation issue has been addressed with refined checking.

[clang-repl] Fix undefined lld::wasm::link symbol while building clangInterpreter for wasm (#113446)

While building llvm (clang, lld) for wasm using emscripten (recipe
hosted on emscripten-forge
https://github.com/emscripten-forge/recipes/tree/main/recipes/recipes_emscripten/llvm)
I ended up with this error
```
 │ │ wasm-ld: error: ../../../../lib/libclangInterpreter.a(Wasm.cpp.o): undefined symbol: lld::wasm::link(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm:
 │ │ :raw_ostream&, bool, bool)
 ```
 This is due to the link function here
 https://github.com/llvm/llvm-project/blob/a4819bd46d8baebc3aaa8b38f78065de33593199/clang/lib/Interpreter/Wasm.cpp#L25-L30

 This was added through this PR (https://github.com/llvm/llvm-project/pull/86402) as an attempt to support running clang-repl and executing C++ code interactively inside a Javascript engine using WebAssembly when built with Emscripten.

 The definition for link is present in lldwasm and when building for the emscripten platform we should be linking against it.

(cherry picked from commit 075581f34035c01659cc883d0d69336c279ef0d5)

[compiler-rt] Stop using x86 builtin on AArch64 with GCC (#93890)

Previously, building `multc3.c` on A64 with GCC 7 or up but 9 and lower
will attempt to reference `__builtin_copysignq`, an [x86-specific
intrinsic][1]:

```
$ gcc -c multc3.c
In file included from fp_lib.h:24,
                 from multc3.c:14:
multc3.c: In function '__multc3':
int_math.h:71:32: warning: implicit declaration of function '__builtin_copysignq'; did you mean '__builtin_copysign'? [-Wimplicit-function-declaration]
 #define crt_copysignf128(x, y) __builtin_copysignq((x), (y))
                                ^~~~~~~~~~~~~~~~~~~
```

This is because `__has_builtin` is from GCC 10, and defined to 0 at the
top of int_math.h for affected GCC versions, so the fallback definition
is used. But `__builtin_copysignq` is unavailable on A64.

Use version detection to find `__builtin_copysignf128` instead. It's
available since GCC 7 and [available][2] on both x86 and A64, given this
macro is only used when `CRT_HAS_IEEE_TF`.

---

I realize this is fixing a problem for an out-of-tree build
configuration, but help would be greatly appreciated. Rust
[builds](https://github.com/rust-lang/compiler-builtins) `multc3.c` with
GCC 8 and this mis-selection is causing [build
issues](https://github.com/rust-lang/rust/issues/125619) way downstream.

ref: d2ce3e9621411f3391def327f89e3a650918989f

[1]: https://gcc.gnu.org/onlinedocs/gcc/x86-Built-in-Functions.html
[2]: https://gcc.gnu.org/gcc-7/changes.html

(cherry picked from commit 8aa9d6206ce55bdaaf422839c351fbd63f033b89)

[LoongArch][Clang] Make the parameters and return value of {x,}vxor.v builti ns `unsigned char` vectors (#114513)

The lsxintrin.h and and lasxintrin.h headers uses `unsigned char`
vectors instead of `signed char` vectors.  GCC also uses `unsigned char`
for them, so align their definition with the headers and GCC.

Fixes #110834.

Depends on #114512.

(cherry picked from commit 4f740f9d77cd038c8e55195fa189748e58ea6476)

[LoongArch][Clang] Make the parameters and return value of {x,}vshuf.b builtins `signed char` vectors (#114512)

The lsxintrin.h and and lasxintrin.h headers uses `signed char` vectors
instead of `unsigned char` vectors.  GCC also uses `signed char` for
them, so align their definition with the headers and GCC.

Depends on #114511.  Part of #110834 fix.

(cherry picked from commit 4006b28d102b09f4c736ef0f2664873305fedcd3)

[LoongArch][Clang] Make the parameter and return value of {x,}vmsknz.b builtins `signed char` vector (#114511)

These builtins operate on int8 vectors, not int16 vectors.  So the old
definition does not make any sense.

Depends on #114510.  Part of #110834 fix.

(cherry picked from commit 92daad2eac587cb0592de019cd5f6cbb7c42bb78)

[LoongArch][clang] Use `signed char` vectors instead of `char` vectors for LSX and LASX builtins (#114510)

`-flax-vector-conversions=none` does not allow an implicit conversion
from `signed char` vector to `char` vector, and we cannot remove
`signed`
from `v16i8` or `v32i8` because doing so will break our expectation with
`-fno-signed-char`.  So to make lsxintrin.h and lasxintrin.h work fine
with `-flax-vector-conversions=none`, we must use `signed char` instead
of `char`.

The change is just done via

    sed 's/V16c/V16Sc/g' -i BuiltinsLoongArchLSX.def
    sed 's/V32c/V32Sc/g' -i BuiltinsLoongArchLASX.def

Depends on #114509.  Part of #110834 fix.

(cherry picked from commit b88505414d47ca267f4df8823309264f78935686)

[LoongArch][Clang] Add tests for #110834 (#114509)

(cherry picked from commit 96d2196f6f73e5712f1df8cd26de8a12c7f24de4)

release/19.x: [Clang] Consider outer instantiation scopes for constraint normalization

Backport 227afac3

[clang-format] Fix a regression in parsing `switch` in macro call (#114506)

Fixes #114408.

(cherry picked from commit 6ca816f88d5f0f2032d1610207023133eaf40a1e)

[compiler-rt] [test] Fix using toolchains that rely on Clang default configs (#113491)

The use of CLANG_NO_DEFAULT_CONFIG in the tests was added because some
Linux distributions had a global default config file, that added flags
relating to hardening, which interfere with the sanitizer tests. By
setting CLANG_NO_DEFAULT_CONFIG, the global default config files that
are found are ignored, and the sanitizers get the expected default
compiler behaviour.

(This was https://github.com/llvm/llvm-project/issues/60394, which was
fixed in 8ab762557fb057af1a3015211ee116a975027e78.)

However, some toolchains may rely on default config files for mandatory
parts required for functioning at all - setting things like sysroots,
-rtlib, -unwindlib, -stdlib, -fuse-ld etc. In such a case we can't
forcibly disable any default config, because it will break the otherwise
working toolchain.

Add a test for whether the compiler works while passing
--no-default-config to it. If the option is accepted and the toolchain
still works while that is set, set CLANG_NO_DEFAULT_CONFIG while running
tests.

(This adds a little bit of inconsistency, as we're testing for the
command line option, while using the environment variable. However doing
compile testing with an environment variable isn't quite as easily
doable, and passing an extra command line flag to all compile commands
while testing, is a bit clumsy - therefore this inconsistency.)

(cherry picked from commit a14a83d9a102253eca7c02ff4c35a2ce3f7de6e5)

[RISCV] Don't delete all fixups in RISCVMCCodeEmitter::expandLongCondBr. (#109513)

The Fixups vector passed into this function may already have fixups in
it from earlier instructions. We should not erase those. We just want to
erase fixups added by this function.

Fixes #108612.

(cherry picked from commit c3d3cef8d58377b02032b07b5f094a402a70435a)

[compiler-rt] [fuzzer] Skip trying to set the thread name on MinGW (#115167)

Since b4130bee6bfd34d8045f02fc9f951bcb5db9d85c, we check for
_LIBCPP_HAS_THREAD_API_PTHREAD to decide between using
SetThreadDescription or pthread_setname_np for setting the thread name.

c6f3b7bcd0596d30f8dabecdfb9e44f9a07b6e4c changed how libcxx defines
their configuration macros - now they are always defined, but defined to
0 or 1, while they previously were either defined or undefined.

As these libcxx defines used to be defined to an empty string (rather
than expanding to 1) if enabled, we can't easily produce an expression
that works both with older and newer libcxx. Additionally, these defines
are libcxx internal config macros that aren't a detail that isn't
supported and isn't meant to be relied upon.

Simply skip trying to set thread name on MinGW as we can't easily know
which kind of thread native handle we have. Setting the thread name is
only a nice to have, quality of life improvement - things should work
the same even without it.

Additionally, libfuzzer isn't generally usable on MinGW targets yet
(Clang doesn't include it in the getSupportedSanitizers() method for the
MinGW target), so this shouldn't make any difference in practice anyway.

(cherry picked from commit 87f4bc0acad65b1d20160d4160c7778b187125fc)

Bump version to 19.1.4

[Serialization] Handle uninitialized type constraints

The ASTWriter currently assumes template type constraints to be
initialized ((bool)getTypeConstraint() == hasTypeConstraint()). Issues
#99036 and #109354 identified a scenario where this assertion is
violated.

This patch removes the assumption and adds another boolean to the
serialization, to explicitly encode whether the type constraint has been
initialized.

The same issue was incidentally fixed on the main branch by #111179.
This solution avoids backporting #111179 and its dependencies.

[clang] Make LazyOffsetPtr more portable (#112927)

LazyOffsetPtr currently relies on uint64_t being able to store a pointer
and, unless sizeof(uint64_t) == sizeof(void *), little endianness, since
getAddressOfPointer reinterprets the memory as a pointer. This also
doesn't properly respect the C++ object model.

As removing getAddressOfPointer would have wide-reaching implications,
improve the implementation to account for these problems by using
placement new and a suitably sized-and-aligned buffer, "right"-aligning
the objects on big-endian platforms so the LSBs are in the same place
for use as the discriminator.

Fixes: bc73ef0031b50f7443615fef614fb4ecaaa4bd11
Fixes: https://github.com/llvm/llvm-project/issues/111993
(cherry picked from commit 76196998e25b98d81abc437708622261810782ca)

[AVR][MC] Fix incorrect range of relative jumps (#109124)

'rjmp .+4094' is legal but rejected by llvm-mc since
86a60e7f1e8f361f84ccb6e656e848dd4fbaa713, and this patch fixed that
range issue.

(cherry picked from commit 8c3b94f420a20a45dd07f3e12d6a6d649858f452)

Fix KCFI types for generated functions with integer normalization (#104826)

With -fsanitize-cfi-icall-experimental-normalize-integers, Clang
appends ".normalized" to KCFI types in CodeGenModule::CreateKCFITypeId,
which changes type hashes also for functions that don't have integer
types in their signatures. However, llvm::setKCFIType does not take
integer normalization into account, which means LLVM generated
functions with KCFI types, e.g. sanitizer constructors, will fail KCFI
checks when integer normalization is enabled in Clang.

Add a cfi-normalize-integers module flag to indicate integer
normalization is used, and append ".normalized" to KCFI types also in
llvm::setKCFIType to fix the type mismatch.

(cherry picked from commit e1c36bde0551977d4b2efae032af6dfc4b2b3936)

[clang-format] Handle template opener/closer in braced list (#112494)

Fixes #112487.

(cherry picked from commit 67f576f31d661897c5da302b8611decb7e0f9237)

[Clang] Disable use of the counted_by attribute for whole struct pointers (#112636)

The whole struct is specificed in the __bdos. The calculation of the
whole size of the structure can be done in two ways:

    1) sizeof(struct S) + count * sizeof(typeof(fam))
    2) offsetof(struct S, fam) + count * sizeof(typeof(fam))

The first will add any remaining whitespace that might exist after
allocation while the second method is more precise, but not quite
expected from programmers. See [1] for a discussion of the topic.

GCC isn't (currently) able to calculate __bdos on a pointer to the whole
structure. Therefore, because of the above issue, we'll choose to match
what GCC does for consistency's sake.

[1] https://lore.kernel.org/lkml/ZvV6X5FPBBW7CO1f@archlinux/

Co-authored-by: Eli Friedman <efriedma@quicinc.com>

[clang] Reject if constexpr in C (#112685)

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

[NFC] fix build failure (#100993)

Fix the build failure caused by
https://github.com/llvm/llvm-project/pull/94944

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

(cherry picked from commit 40b4fd7a3e81d32b29364a1b15337bcf817659c0)

[WebAssembly] Fix feature coalescing (#110647)

This fixes a problem introduced in #80094. That PR copied negative
features from the TargetMachine to the end of the feature string. This
is not correct, because even if we have a baseline TM of say `-simd128`,
but a function with `+simd128`, the coalesced feature string should have
`+simd128`, not `-simd128`.

To address the original motivation of that PR, we should instead
explicitly materialize the negative features in the target feature
string, so that explicitly disabled default features are honored.

Unfortunately, there doesn't seem to be any way to actually test this
using llc, because `-mattr` appends the specified features to the end of
the `"target-features"` attribute. I've tested this locally by making it
prepend the features instead.

(cherry picked from commit 5a7b79c93e2e0c71aec016973f5f13d3bb2e7a62)

Bump version to 19.1.3

[LLVM] [Clang] Backport "Support for Gentoo `*t64` triples (64-bit time_t ABIs)"

This is a backport of 387b37af1aabf325e9be844361564dfad8d45c75 for 19.x,
adjusted to add new Triple::EnvironmentType members at the end to avoid
breaking backwards ABI compatibility.

Gentoo is planning to introduce a `*t64` suffix for triples that will be
used by 32-bit platforms that use 64-bit `time_t`. Add support for
parsing and accepting these triples, and while at it make clang
automatically enable the necessary glibc feature macros when this suffix
is used.

[Clang] Instantiate Typedefs referenced by type alias deduction guides (#111804)

TypedefNameDecl referenced by a synthesized CTAD guide for type aliases
was not transformed previously, resulting in a substitution failure in
BuildDeductionGuideForTypeAlias() when substituting into the
right-hand-side deduction guide.

This patch fixes it in the way we have been doing since
https://reviews.llvm.org/D80743. We transform all the function
parameters, parenting referenced TypedefNameDecls with the
CXXDeductionGuideDecl. Then we instantiate these declarations in
FindInstantiatedDecl() as we build up the eventual deduction guide,
using the mechanism introduced in D80743

Fixes #111508

(cherry picked from commit 0bc02b999a9686ba240b7a68d3f1cbbf037d2170)

 [Inliner] Don't propagate access attr to byval params (#112256)

- **[Inliner] Add tests for bad propagationg of access attr for `byval`
param; NFC**
- **[Inliner] Don't propagate access attr to `byval` params**

We previously only handled the case where the `byval` attr was in the
callbase's param attr list. This PR also handles the case if the
`ByVal` was a param attr on the function's param attr list.

(cherry picked from commit 3c777f04f065dda5f0c80eaaef2a7f623ccc20ed)

Undef _TIME_BITS along with _FILE_OFFSET_BITS

This change is identical to
26800a2c7e7996dc773b4e990dd5cca41c45e1a9 ("[sanitizer] Undef
_TIME_BITS along with _FILE_OFFSET_BITS on Linux"), but for
sanitizer_procmaps_solaris.cpp.

Indeed, even though sanitizer_procmaps_solaris.cpp is Solaris
specific, it also gets built on Linux platforms. It also includes
sanitizer_platform.h, which also ends up including features-time64.h,
causing a build failure on 32-bit Linux platforms on which 64-bit
time_t is enabled by setting _TIME_BITS=64.

To fix this, we do the same change: undefine _TIME_BITS, which anyway
will cause no harm as the rest of this file is inside a
SANITIZER_SOLARIS compile-time conditional.

Fixes:

In file included from /home/thomas/buildroot/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/include/features.h:394,
                 from ../../../../libsanitizer/sanitizer_common/sanitizer_platform.h:25,
                 from ../../../../libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp:14:
/home/thomas/buildroot/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is al
lowed only with _FILE_OFFSET_BITS=64"
   26 | #   error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
      |     ^~~~~

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Closes: https://github.com/llvm/llvm-project/pull/99699
(cherry picked from commit a1217020da219386b29c1a5a4a217904ecf07d7d)

[clang-repl] [codegen] Reduce the state in TBAA. NFC for static compilation. (#98138)

In incremental compilation clang works with multiple `llvm::Module`s.
Our current approach is to create a CodeGenModule entity for every new
module request (via StartModule). However, some of the state such as the
mangle context needs to be preserved to keep the original semantics in
the ever-growing TU.

Fixes: llvm/llvm-project#95581.
cc: @jeaye
(cherry picked from commit 6c62ad446b2441b78ae524d9e700e351d5a76394)

[Headers] [ARM64EC] Fix extra tokens inside intrin0.h preprocessor directive (#112066)

Fixes https://github.com/llvm/llvm-project/pull/87717.

(cherry picked from commit 9bf68c2400e8966511332dfbf5c0f05e8a3300fa)

[lld][Hexagon] Support predicated-add GOT_16_X mask lookup (#111896)

When encountering an instruction like `if (p0) r0 = add(r0,##bar@GOT)`,
lld would fail with:
```
ld.lld: error: unrecognized instruction for 16_X type: 0x7400C000
```

This issue was encountered while building libreadline with clang 19.1.0.

Fixes: #111876
(cherry picked from commit 77aa8257acbd773c0c430cd962da1bcfbd5ee94b)

[InstCombine] Drop range attributes in `foldIsPowerOf2` (#111946)

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

[clang-format] Handle template closer followed by braces (#110971)

Fixes #110968.

(cherry picked from commit e5b05a51b8151cc7788bbdea4d491e5ccfceedea)

[compiler-rt] Remove SHA2 interceptions for NetBSD/FreeBSD. (#110246)

To Fix #110215

Interceptors introduced with 18a7ebda99044473fdbce6376993714ff54e6690

(cherry picked from commit d0b9c2c5647656738cda3fb670aa5d3b3a69d784)

Update test since trunk

[VectorCombine] Do not try to operate on OperandBundles. (#111635)

This bails out if we see an intrinsic with an operand bundle on it, to
make sure we don't process the bundles incorrectly.

Fixes #110382.

(cherry picked from commit c136d3237a3c6230cfe1ab3f0f6790f903c54a27)

[Clang] Improve type traits recognition in `__has_builtin` (#111516)

`__has_builtin` was relying on reversible identifiers and string
matching to recognize builtin-type traits, leading to some newer type
traits not being recognized.

Fixes #111477

[x86] combineMUL - when looking for a vector multiply by splat constant, ensure we're only accepting ConstantInt splat scalars.

Fixes #111170

(cherry picked from commit 9459d729d22b7bfedad9d3a4237162077c6984a4)

Move out of line

FastISel: Fix incorrectly using getPointerTy (#110465)

This was using the default address space instead of the
correct one.

Fixes #56055

Keep old method around for ABI compatibility on the release branch.

(cherry picked from commit 81ba95cefe1b5a12f0a7d8e6a383bcce9e95b785)

[libc++] Avoid re-exporting a few specific symbols from libc++abi (#109054)

In 6a884a9aef39, I synchronized the export list of libc++abi to the
export list of libc++. From the linker's perspective, this caused these
symbols to be taken from libc++.dylib instead of libc++abi.dylib.

However, that can be problematic when back-deploying. Indeed, this means
that the linker will encode an undefined reference to be fullfilled by
libc++.dylib, but when backdeploying against an older system, that
symbol might only be available in libc++abi.dylib.

Most of the symbols that started being re-exported after 6a884a9aef39
turn out to be implementation details of libc++abi, so nobody really
depends on them and this back-deployment issue is inconsequential.

However, we ran into issues with a few of these symbols while testing
LLVM 19, which led to this patch. This slipped between the cracks and
that is why the patch is coming so long after the original patch landed.

In the future, a follow-up cleanup would be to stop exporting most of
the _cxxabiv1_foo_type_infoE symbols from both libc++abi and libc++
since they are implementation details that nobody should be relying on.

rdar://131984512
(cherry picked from commit 677e8cd6ff51e178bcb4669104763f71a2de106c)

[libc++] Adjust the version of __cpp_lib_ranges in C++20 mode

This is a (very partial) cherry-pick of #101715 to fix this oversight
in the LLVM 19 release.

[Clang] Check that we have the correct RecordDecl

Ensure we have the correct RecordDecl before returning the Expr we're
looking for.

[Clang] Fix 'counted_by' for nested struct pointers (#110497)

Fix counted_by attribute for cases where the flexible array member is
accessed through struct pointer inside another struct:

```
struct variable {
        int a;
        int b;
        int length;
        short array[] __attribute__((counted_by(length)));
};

struct bucket {
        int a;
        struct variable *growable;
        int b;
};
```

__builtin_dynamic_object_size(p->growable->array, 0);

This commit makes sure that if the StructBase is both a MemberExpr and a
pointer, it is treated as a pointer. Otherwise clang will generate to
code to access the address of p->growable intead of loading the value of
p->growable->length.

Fixes #110385

[SystemZ] Fix codegen for _[u]128 intrinsics

PR #74625 introduced a regression in the code generated for the
following set of intrinsic:
  vec_add_u128, vec_addc_u128, vec_adde_u128, vec_addec_u128
  vec_sub_u128, vec_subc_u128, vec_sube_u128, vec_subec_u128
  vec_sum_u128, vec_msum_u128
  vec_gfmsum_128, vec_gfmsum_accum_128

This is because the new code incorrectly assumed that a cast
from "unsigned __int128" to "vector unsigned char" would simply
be a bitcast re-interpretation; instead, this cast actually
truncates the __int128 to char and splats the result.

Fixed by adding an intermediate cast via a single-element
128-bit integer vector.

Fixes: https://github.com/llvm/llvm-project/issues/109113
(cherry picked from commit baf9b7da81025c1e3b0704d7ecf667e06f95642b)

[Clang] Remove the special-casing for RequiresExprBodyDecl in BuildResolvedCallExpr() after fd87d765c0 (#111277)

The special-casing for RequiresExprBodyDecl caused a regression, as
reported in #110785.

The original fix for #84020 has been superseded by fd87d765c0, which
establishes a `DependentScopeDeclRefExpr` instead of a
`CXXDependentScopeMemberExpr` for the case in issue. So the spurious
diagnostic in #84020 would no longer occur.

This also merges the test for #84020 together with that for #110785 into
clang/test/SemaTemplate/instantiate-requires-expr.cpp.

No release note because I think this merits a backport.

Fixes #110785

(cherry picked from commit 8c1547055eaf65003f3e6fd024195f4926ff2356)

[clang-tidy] Avoid capturing a local variable in a static lambda in UseRangesCheck (#111282)

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

(cherry picked from commit acf92a47c0ece8562fd745215c478fe2d4ab5896)

[clang-format] Handle template closer followed by empty paretheses (#110408)

Fixes #109925.

[x86][Windows] Fix chromium build break
Windows does not support float C89 math functions like:
- acosf
- asinf
- atanf
- coshf
- sinhf
- tanhf
These 6 libfuncs need to be type promoted.

This PR fixes the bug introduced by https://github.com/llvm/llvm-project/pull/98949

workflows/release-binaries: Use static ZSTD on macOS

On macOS the shared zstd library points to a homebrew install that isn't
very stable for users.

(cherry picked from commit 748f5404ccdf28d4beef37efdaeba7a1701ab425)

[libc++] Fix name of is_always_lock_free test which was never being run (#106077)

(cherry picked from commit b45661953e6974782b0ccada6f0784db04bc693f)

workflows/release-documentation: Submit a pull request with changes (#108247)

This is instead of pushing directly. Creating a pull request is slightly
more work for the release manager, but it is more secure as we no longer
need a secret with write access to the www-releases repo.

(cherry picked from commit 9cd289fa4a7355e1bfd3129ba9c755f979fd0a72)

workflow/release-binaries: Checkout sources before downloading artifacts (#109349)

The actions/checkout step will clear the current directory, so we need
to checkout the sources first so that the downloaded artifacts won't be
deleted.

(cherry picked from commit 8f2aa9dbad7c1400f66e1ee1c43b071a1905f3e6)

Fix libFuzzer not building with pthreads on Windows (#109525)

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

(cherry picked from commit b4130bee6bfd34d8045f02fc9f951bcb5db9d85c)

[libc++] Follow-up to "Poison Pills are Too Toxic"

* Update release notes and `Cxx23.html`
* Update `__cpp_lib_ranges` feature test macro

Bump version to 19.1.2

[X86][APX] Do not emit {evex} prefix for memory variant (#109759)

This was mistakely changed by #109579, which doesn't match with other
EVEX decoding.

(cherry picked from commit 70529b24a30943d46e361d2990268499921e28a2)

[X86][APX] Fix wrong encoding of promoted KMOV instructions due to missing NoCD8 (#109579)

Promoted KMOV* was encoded with CD8 incorrectly, see
https://godbolt.org/z/cax513hG1

(cherry picked from commit 0d334d83a4c7ce16fa1bc0e5e56bbdeaf01c2b2d)

[CodeGen] Clear InitUndef pass new register cache between pass runs (#90967)

Multiple invocations of the pass could interfere with eachother,
preventing some undefs being initialised.

I found it very difficult to create a unit test for this due to it being
dependent on particular allocations of a previous function. However, the
bug can be observed here: https://godbolt.org/z/7xnMo41Gv with the
creation of the illegal instruction `vnsrl.wi v9, v8, 0`

[libcxx][test] Use smaller time range for 32 bit time_t (#104762)

This fixes the test on Arm 32 bit Ubuntu Jammy where time_t is 32 bit.

(cherry picked from commit cdd608b8f0ce090b3568238387df368751bdbb5d)

[lldb][test] Mark sys_info zdump test unsupported on 32 bit Arm Linux

Until https://github.com/llvm/llvm-project/pull/103056 lands
or another more appropriate check can be found.

This test fails on Ubuntu Focal where zdump is built with 32 bit time_t
but passes on Ubuntu Jammy where zdump is built with 64 bit time_t.

Marking it unsupported means Linaro can upgrade its bots to Ubuntu
Jammy without getting an unexpected pass.

(cherry picked from commit 6f6422f4a2b8647a59936c131e50a79906d89510)

Bump version to 19.1.1

AMDGPU: Fix inst-selection of large scratch offsets with sgpr base (#110256)

Use i32 for offset instead of i16, this way it does not get interpreted
as negative 16 bit offset.

(cherry picked from commit 83fe85115da9dc25fa270d2ea8140113c8d49670)

AMDGPU: Add test for 16 bit unsigned scratch offsets (#110255)

Large scratch offset with one on highest bit selected as negative,
negative offset has same binary representation in 16 bits as large
unsigned offset.

(cherry picked from commit e9d12a6b451bd403d95105aa976a011dc821f126)

[libc++] Fix AppleClang version number when checking for __builtin_verbose_trap support (#110161)

We should have been checking against 1700, not 17000, which was a typo.

(cherry picked from commit 1eba87904b0cbaaee82cfdb835528b85d99320ef)

[SDAG] Honor signed arguments in floating point libcalls (#109134)

In ExpandFPLibCall, an assumption is made that all floating point
libcalls that take integer arguments use unsigned integers. In the case
of ldexp and frexp, this assumption is incorrect, leading to
miscompilation and subsequent target-dependent incorrect operation.

Indicate that ldexp and frexp utilize signed arguments in
ExpandFPLibCall.

Fixes #108904

Signed-off-by: Timothy Pearson <tpearson@solidsilicon.com>
(cherry picked from commit 90c14748638f1e10e31173b145fdbb5c4529c922)

[LoongArch] Fix the assertion for atomic store with 'ptr' type

(cherry picked from commit 63267ca9016aa334b329aa408716456b4e3799c8)

[clang-scan-deps] Don't inspect Args[0] as an option (#109050)

Since a26ec542371652e1d774696e90016fd5b0b1c191, we expand the executable
name to an absolute path, if it isn't already one, if found in path.

This broke a couple tests in some environments; when the clang workdir
resides in a path under e.g. /opt. Tests that only use a tool name like
"clang-cl" would get expanded to the absolute path in the build tree.
The loop for finding the last "-o" like option for clang-cl command
lines would inspect all arguments, including Args[0] which is the
executable name itself. As an /opt path matches Arg.starts_with("/o"),
this would get detected as an object file output name in cases where
there was no other explicit output argument.

Thus, this fixes those tests in workdirs under e.g. /opt.

(cherry picked from commit cead9044a995910306e2e64b426fcc8042d7e0ef)

[clang-scan-deps] Infer the tool locations from PATH (#108539)

This allows the clang driver to know which tool is meant to be executed,
which allows the clang driver to load the right clang config files, and
allows clang to find colocated sysroots.

This makes sure that doing `clang-scan-deps -- <tool> ...` looks up
things in the same way as if one just would execute `<tool> ...`, when
`<tool>` isn't an absolute or relative path.

(cherry picked from commit a26ec542371652e1d774696e90016fd5b0b1c191)

[clang-scan-deps] Fix builds with BUILD_SHARED_LIBS=ON

This fixes building in this configuration after
87e1104cf0e2de0d04bee2944893fa7897277b2f.

(cherry picked from commit aa3465793a250faa5426ac626989375465256658)

[clang-scan-deps] Infer the target from the executable name (#108189)

This allows clang-scan-deps to work correctly when using cross compilers
with names like <triple>-clang.

(cherry picked from commit 87e1104cf0e2de0d04bee2944893fa7897277b2f)

[LoopPeel] Fix LCSSA phi node invalidation

In the test case, the BECount of the second loop uses %load,
but we only have an LCSSA phi node for %add, so that is what
gets invalidated. Use the forgetLcssaPhiWithNewPredecessor()
API instead, which will invalidate the roots of the expression
instead.

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

(cherry picked from commit 5bcc82d43388bb0daa122d5fe7ecda5eca27fc16)

[LoongArch] Eliminate the redundant sign extension of division (#107971)

If all incoming values of `div.d` are sign-extended and all users only
use the lower 32 bits, then convert them to W versions.

Fixes: #107946
(cherry picked from commit 0f47e3aebdd2a4a938468a272ea4224552dbf176)

 [LoongArch][ISel] Check the number of sign bits in `PatGprGpr_32` (#107432)

After https://github.com/llvm/llvm-project/pull/92205, LoongArch ISel
selects `div.w` for `trunc i64 (sdiv i64 3202030857, (sext i32 X to
i64)) to i32`. It is incorrect since `3202030857` is not a signed 32-bit
constant. It will produce wrong result when `X == 2`:
https://alive2.llvm.org/ce/z/pzfGZZ

This patch adds additional `sexti32` checks to operands of
`PatGprGpr_32`.
Alive2 proof: https://alive2.llvm.org/ce/z/AkH5Mp

Fix #107414.

(cherry picked from commit a111f9119a5ec77c19a514ec09454218f739454f)

[DAGCombiner] cache negative result from getMergeStoreCandidates() (#106949)

Cache negative search result from getStoreMergeCandidates() so that
mergeConsecutiveStores() does not iterate quadratically over a
potentially long sequence of unmergeable stores.

(cherry picked from commit 8f77d37f256809766fd83a09c6d144b785e9165a)

[Clang][CodeGen] Fix type for atomic float incdec operators (#107075)

`llvm::ConstantFP::get(llvm::LLVMContext&, APFloat(float))` always
returns a f32 constant.
Fix https://github.com/llvm/llvm-project/issues/107054.

[libc++] Disable the clang-tidy checks to get CI back (#109989)

The CI has been a complete mess for the past week, and the only thing
preventing it from being back is the Clang tidy checks. Disable them (as
a total hack) to get CI back.

(cherry picked from commit 78c6506543dee13c9335edc5c85bc73c4853fbd7)

[C++20] [Modules] Add Decl::isFromGlobalModule

[ORC] Remove EDU from dependants list of dependencies before destroying.

Dependant lists hold raw pointers back to EDUs that depend on them. We need to
remove these entries before destroying the EDU or we'll be left with a dangling
reference that can result in use-after-free bugs.

No testcase: This has only been observed in multi-threaded setups that
reproduce the issue inconsistently.

rdar://135403614
(cherry picked from commit 7034ec491251e598d2867199f89fefa3eb16a1a0)

workflows/release-binaries: Enable flang builds on Windows (#101344)

Flang for Windows depends on compiler-rt, so we need to enable it for
the stage1 builds. This also fixes failures building the flang tests on
macOS.

Fixes #100202.

(cherry picked from commit 8927576b8f6442bb6129bda597efee46176f8aec)

[Inliner] Fix bug where attributes are propagated incorrectly (#109347)

- **[Inliner] Add tests for incorrect propagation of return attrs; NFC**
- **[Inliner] Fix bug where attributes are propagated incorrectly**

The bug stems from the fact that we assume the new (inlined) callsite
is calling the same function as the original (callee) callsite. While
this is typically the case, since `VMap` simplifies the new
instructions, callee intrinsics callsites can end up not corresponding
with the same function.

This can lead to buggy propagation.

(cherry picked from commit a9352a0d31862c15146ca863bde165498e9a80e8)

[AA] Take account of C++23's stricter rules for forward declarations (NFC) (#109416)

C++23 has stricter rules for forward declarations around
std::unique_ptr, this means that the inline declaration of the
constructor was failing under clang in C++23 mode, switching to an
out-of-line definition of the constructor fixes this.

This was fairly major impact as it blocked inclusion of a lot of headers
under clang in C++23 mode.

Fixes #106597.

(cherry picked from commit 76bc1eddb2cf8b6cc073649ade21b59bbed438a2)

[clang-format] Reimplement InsertNewlineAtEOF (#108513)

Fixes #108333.

(cherry picked from commit 7153a4bbf6d46e58ce32d59220515c5ab9f35691)

[C++20] [Modules] Treat in class defined member functions in language linkage as implicitly inline

Close https://github.com/llvm/llvm-project/issues/108732

This looks liek an oversight mostly.

(cherry picked from commit 7046a9fb05f65f4699a2e88abbcb7dad8a21db2d)

[C++20] [Modules] Treat constexpr/consteval member function as implicitly inline

Close https://github.com/llvm/llvm-project/issues/107673

(cherry picked from commit 74ac96ae1a81c7ecc0e27ff6f45309cff1f2df97)

[X86] Fix missing check of rotate <-> shift equivilence (Issue 108722)

Previous code was checking that rotate and shift where equivilent when
transforming shift -> rotate but not the other way around.

Closes #108767

(cherry picked from commit 81279bf97f187eee0446af00d8ae9ec32a22e878)

[X86] Add test for issue 108722; NFC

(cherry picked from commit 1c378d2b145578948942512f9d6985e37659d013)