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)

[LoongArch] Codegen for concat_vectors with LASX

Fixes: #107355
Reviewed By: SixWeining

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

(cherry picked from commit 1ca411ca451e0e86caf9207779616f32ed9fd908)

[lldb][test] TestDbgInfoContentVectorFromStdModule.py: skip test on Darwin (#108003)

This started failing on the macOS CI after
https://github.com/llvm/llvm-project/pull/106885:

```
  lldb-api :: commands/expression/import-std-module/vector-dbg-info-content/TestDbgInfoContentVectorFromStdModule.py

"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang"  -std=c++11 -g -O0 -isysroot "/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk" -arch arm64  -I/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/make/../../../../..//include -I/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/tools/lldb/include -I/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content -I/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/make -include /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/make/test_common.h  -fno-limit-debug-info    -nostdlib++ -nostdinc++ -cxx-isystem /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/include/c++/v1  --driver-mode=g++ -MT main.o -MD -MP -MF main.d -c -o main.o /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content/main.cpp
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang"  main.o -g -O0 -isysroot "/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.2.sdk" -arch arm64  -I/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/make/../../../../..//include -I/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/tools/lldb/include -I/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/commands/expression/import-std-module/vector-dbg-info-content -I/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/make -include /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/make/test_common.h  -fno-limit-debug-info     -L/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/lib -Wl,-rpath,/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/lib -lc++ --driver-mode=g++ -o "a.out"
ld: warning: ignoring duplicate libraries: '-lc++'
codesign --entitlements /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/packages/Python/lldbsuite/test/make/entitlements-macos.plist -s - "a.out"
"/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/./bin/dsymutil"  -o "a.out.dSYM" "a.out"

runCmd: settings set target.import-std-module true

output:

runCmd: expr std::reverse(a.begin(), a.end())

Assertion failed: (isa<InjectedClassNameType>(Decl->TypeForDecl)), function getInjectedClassNameType, file ASTContext.cpp, line 5057.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0. HandleCommand(command = "expr std::reverse(a.begin(), a.end())")
1. <eof> parser at end of file
2. /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/include/c++/v1/__algorithm/reverse.h:54:1: instantiating function definition 'std::reverse<std::__wrap_iter<Foo *>>'
3. /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/include/c++/v1/__algorithm/reverse.h:47:58: instantiating function definition 'std::__reverse<std::_ClassicAlgPolicy, std::__wrap_iter<Foo *>, std::__wrap_iter<Foo *>>'
4. /Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/include/c++/v1/__algorithm/reverse.h:40:1: instantiating function definition 'std::__reverse_impl<std::_ClassicAlgPolicy, std::__wrap_iter<Foo *>>'
```

(cherry picked from commit 2bcab9ba7139cfa96c85433fa85b29c8a6d7008b)

[lldb] Fix some tests that fail with system libstdc++ (#106885)

This is a revert of b1fcc1840c312472cb9ccb8c4e5e02ca13b31113.

These tests weren't working on Ubuntu 22.04 or Fedora 37-40. I'm not
sure exactly why, but it seems like they may be incompatible with
libstdc++. Also, despite the fact that the tests were using the system
libstdc++, the tests were only run when libcxx was enabled.

I tested this with a RelWithDebInfo build and the tests passed.

Fixes #106475

(cherry picked from commit adf44d5c3ea03569f019740e1140c3205810b3fa)

[AVR] Fix 16-bit LDDs with immediate overflows (#104923)

16-bit loads are expanded into a pair of 8-bit loads, so the maximum
offset of such 16-bit loads must be 62, not 63.

(cherry picked from commit c7a4efa4294789b1116f0c4a320c16fcb27cb62c)

[Clang][Concepts] Fix the constraint equivalence checking involving parameter packs (#102131)

We established an instantiation scope in order for constraint
equivalence checking to properly map the uninstantiated parameters.

That mechanism mapped even packs to themselves. Consequently, parameter
packs e.g. appearing in a function call, were not expanded. So they
would end up becoming `SubstTemplateTypeParmPackType`s that circularly
depend on the canonical declaration of the function template, which is
not yet determined, hence the spurious error.

No release note as I plan to backport it to 19.

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

---------

Co-authored-by: cor3ntin <corentinjabot@gmail.com>
(cherry picked from commit e6974daa7bc100c8b88057d50f3ec3eca7282243)

[ELF] --icf: don't fold a section without relocation and a section with relocations for SHT_CREL

Similar to commit 686cff17cc310884e48ae963bf7507f96950cc90 for SHT_REL (#57693).
CREL hasn't been tested with ICF before.

And avoid a pitfall that eqClass[0] might interfere with ICF.

(cherry picked from commit e82f0838ae88ad69515ebec234765e3e2607bebf)

[LoongArch][sanitizer] Fix SC_ADDRERR_{RD,WR} missing in the musl environment (#108557)

Fixes #108550

(cherry picked from commit 1825cf28dc83113200b623ebcf063eea35ade79a)

Reland [llvm-ml] Fix RIP-relative addressing for ptr operands (#108061)

Relands #107618 with fix for assertion triggered by OpenMP runtime MASM
assembly source.

(cherry picked from commit 7574e1ddc4be63628cb7617857cc8938058a79d2)

[bolt][tests] Skip tests that use perf when perf counters are unavailable (#107892)

On the GitHub Action runners, perf always fails with the error below ,
so we need to skip the perf tests on platforms like this that have
limited access to the perf counters.

```
Access to performance monitoring and observability operations is limited.
Consider adjusting /proc/sys/kernel/perf_event_paranoid setting to open
access to performance monitoring and observability operations for processes
without CAP_PERFMON, CAP_SYS_PTRACE or CAP_SYS_ADMIN Linux capability.
More information can be found at 'Perf events and tool security' document:
https://www.kernel.org/doc/html/latest/admin-guide/perf-security.html
perf_event_paranoid setting is 4:
  -1: Allow use of (almost) all events by all users
      Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK
>= 0: Disallow raw and ftrace function tracepoint access
>= 1: Disallow CPU event access
>= 2: Disallow kernel profiling
To make the adjusted perf_event_paranoid setting permanent preserve it
in /etc/sysctl.conf (e.g. kernel.perf_event_paranoid = <setting>)
```

(cherry picked from commit 773353b20a49bfa0dab608d415c1b4734d037fce)

[clang] Don't add DWARF debug info when assembling .s with clang-cl /Z7 (#106686)

This fixes a regression from f58330cbe44598eb2de0cca3b812f67fea0a71ca.

That commit changed the clang-cl options /Zi and /Z7 to be implemented
as aliases of -g rather than having separate handling.

This had the unintended effect, that when assembling .s files with
clang-cl, the /Z7 option (which implies using CodeView debug info) was
treated as a -g option, which causes `ClangAs::ConstructJob` to pick up
the option as part of `Args.getLastArg(options::OPT_g_Group)`, which
sets the `WantDebug` variable.

Within `Clang::ConstructJob`, we check for whether explicit `-gdwarf` or
`-gcodeview` options have been set, and if not, we pick the default
debug format for the current toolchain. However, in `ClangAs`, if debug
info has been enabled, it always adds DWARF debug info.

Add similar logic in `ClangAs` - check if the user has explicitly
requested either DWARF or CodeView, otherwise look up the toolchain
default. If we (either implicitly or explicitly) should be producing
CodeView, don't enable the default `ClangAs` DWARF generation.

This fixes the issue, where assembling a single `.s` file with clang-cl,
with the /Z7 option, causes the file to contain some DWARF sections.
This causes the output executable to contain DWARF, in addition to the
separate intended main PDB file.

By having the output executable contain DWARF sections, LLDB only looks
at the (very little) DWARF info in the executable, rather than looking
for a separate standalone PDB file. This caused an issue with LLDB's
tests, https://github.com/llvm/llvm-project/issues/101710.

(cherry picked from commit fcb7b390ccd5b4cfc71f13b5e16a846f3f400c10)

Bump version to 19.1.0 (final)

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

This reverts commit 78654faa0c6d9dc2f72b81953b9cffbb7675755b.

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

This reverts commit d752f29fb333d47724484e08b32d6499cc1e460e.

[PowerPC] Fix assert exposed by PR 95931 in LowerBITCAST (#108062)

Hit Assertion failed: Num < NumOperands && "Invalid child # of SDNode!"
Fix by checking opcode and value type before calling getOperand.

(cherry picked from commit 22067a8eb43a7194e65913b47a9c724fde3ed68f)

[X86] AMD Zen 5 Initial enablement

[lld] select a default eflags for hexagon (#108431)

Empty archives are apparently routine in linux kernel builds, so instead
of asserting, we should handle this case with a sane default value.

(cherry picked from commit d1ba432533aafc52fc59158350af937a8b6b9538)

Guard an include of `<ostream>` in `<chrono>` with availability macro (#108429)

This fixes a regression introduced in
https://github.com/llvm/llvm-project/pull/96035.

(cherry picked from commit 127c34948bd54e92ef2ee544e8bc42acecf321ad)

[RISCV] Don't outline pcrel_lo when the function has a section prefix (#107943)

GNU ld will error when encountering a pcrel_lo whose corresponding
pcrel_hi is in a different section. [1] introduced a check to help
prevent this issue by preventing outlining in a few circumstances.
However, we can also hit this same issue when outlining from functions
with prefixes ("hot"/"unlikely"/"unknown" from profile information, for
example) as the outlined function might not have the same prefix,
possibly resulting in a "paired" pcrel_lo and pcrel_hi ending up in
different sections.

To prevent this issue, take a similar approach as [1] and additionally
prevent outlining when we see a pcrel_lo and the function has a prefix.

[1]
https://github.com/llvm/llvm-project/commit/96c85f80f0d615ffde0f85d8270e0a8c9f4e5430

Fixes #107520

(cherry picked from commit 866b93e6b33fac9a4bc62bbc32199bd98f434784)

[Clang] Fix crash due to invalid source location in __is_trivially_equality_comparable (#107815)

Fixes #107777

(cherry picked from commit 6dbdb8430b492959c399a7809247424c6962902f)

[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)