This fixes some build bots if we reland D150505: specifically when using GCC to
build LLVM and then `-fno-lifetime-dse` ends up passed to compile_commands.json
and causing clang-tidy to pick up the Clang unknown option.

(cherry picked from commit 626849c7)

The x86_intrcc calling convention will build two STACKALLOC_W_PROBING machine instructions if the function takes an error code. This is caused by an additional call to emitSPUpdate in llvm/lib/Target/X86/X86FrameLowering.cpp:1650. Previously only the first STACKALLOC_W_PROBING machine instruction was properly handled, the second one was simply ignored. This lead to miscompilations where the stack pointer wasn't properly updated (see https://github.com/rust-lang/rust/issues/109918). This patch fixes this by handling all STACKALLOC_W_PROBING machine instructions.

To be honest I don't quite understand why this didn't lead to more noticeable miscompilations previously.

This is my first time contributing to LLVM.

Reviewed By: pengfei

Differential Revision: https://reviews.llvm.org/D150033

(cherry picked from commit f6154364)

D142279 enabled assertion in libstdc++ and one was triggered
in the PFTBuilder because an optional was access even if it was
null.
This patch fix this issue and add a regression test.

Reviewed By: jeanPerier

Differential Revision: https://reviews.llvm.org/D143589

(cherry picked from commit 3f55311a)

Previously, when checking whether an in-class initializer exists when
performing parenthesized aggregate initialization, Clang checks that the
output of FieldDecl::getInClassInitializer() is non-null. This is
incorrect; if the field is part of a templated type, then
getInClassInitializer() will return nullptr if we haven't called
Sem::BuildCXXDefaultInitExpr(...) before, even if
FieldDecl::hasInClassInitializer() returns true. The end result is that
Clang incorrectly ignores the in class initializer and
value-initializes the field. The fix therefore is to instead call
FieldDecl::hasInClassInitializer(), which is what we do for braced init
lists [0].

Before this patch, Clang does correctly recognize the in-class field
initializer in certain cases. This is Sema::BuildCXXDefaultInitExpr(...)
populates the in class initializer of the corresponding FieldDecl
object. Therefore, if that method was previously called with the same
FieldDecl object, as can happen with a decltype(...) or a braced list
initialization, FieldDecl::getInClassInitializer() will return a
non-null expression, and the field becomes properly initialized.

Fixes 62266

[0]: https://github.com/llvm/llvm-project/blob/be5f35e24f4c15caf3c4aeccddc54c52560c28a0/clang/lib/Sema/SemaInit.cpp#L685

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D149389

The new test case showed that the NoPHIs flag needs to be cleared.

Original commit message:

[SystemZ] Bugfix in expansion of memmem operations.

Since NC, OC, and XC clobber CC, the EXRL_Pseudo targeting these must also be
marked to do so.

Original patch by uweigand.

Reviewed by: uweigand

Differential Revision: https://reviews.llvm.org/D150251

Fixes: https://github.com/llvm/llvm-project/issues/62572
(cherry picked from commit 655f0fc4)

Mark the two dfsan tests that are known to be broken on glibc-2.37
as XFAIL, to make the test suite start passing on Gentoo again.

Bug: https://github.com/llvm/llvm-project/issues/60678

Differential Revision: https://reviews.llvm.org/D148496

(cherry picked from commit 488a4b24)

Currently the driver does not propagate the `-f[no-]emulated-tls` flags
to the linker under LTO. This can be surprising when the platform
defaults differ from the flags being passed. A related discussion can be
found in https://reviews.llvm.org/D143619. While the focus there was
RISC-V support, the root cause was that setting `-femualted-tls` and
`-flto` when compiling with Clang resulted in missing symbols because
the platform defaults for Android differed from the flags being passed
to Clang.

This patch changes the Clang driver's behavior to pass the emulated-tls
flags through to the linker when compiling with LTO/ThinLTO.

Reviewed By: phosek, vit9696

Differential Revision: https://reviews.llvm.org/D147834

(cherry picked from commit a78816a6)

These tests have been failing on 32-bit machines.

https://github.com/llvm/llvm-project/issues/62184.
(cherry picked from commit 2cd2fb43)

Bug was because we recognized patterns like `(shl 4, Z)` as a power of
2 we could take Log2 of (`2 + Z`), but doing `(shl X, (2 + Z))` can
cause a poison shift.
    https://alive2.llvm.org/ce/z/yuJm_k

The fix is to verify that `Log2(Y)` will be a non-poisonous shift
amount. We can do this with:
    `nsw` flag:
        - https://alive2.llvm.org/ce/z/yyyJBr
        - https://alive2.llvm.org/ce/z/YgubD_
    `nuw` flag:
        - https://alive2.llvm.org/ce/z/-4mpyV
        - https://alive2.llvm.org/ce/z/a6ik6r
    Prove `Y != 0`:
        - https://alive2.llvm.org/ce/z/ced4su
        - https://alive2.llvm.org/ce/z/X-JJHb

Reviewed By: nikic

Differential Revision: https://reviews.llvm.org/D148609

* Fix an issue where temporaries initialized via parenthesized aggregate
  initialization don't get destroyed.
* Fix an issue where aggregate initialization omits calls to class
  members' move constructors after a TreeTransform. This occurs because
  the CXXConstructExpr wrapping the call to the move constructor gets
  unboxed during a TreeTransform of the wrapping FunctionalCastExpr (as with a
  InitListExpr), but unlike InitListExpr, we dont reperform the
  InitializationSequence for the list's expressions to regenerate the
  CXXConstructExpr. This patch fixes this bug by treating
  CXXParenListInitExpr identically to InitListExpr in this regard.

Fixes #61145

Reviewed By: rsmith

Differential Revision: https://reviews.llvm.org/D146465

(cherry picked from commit 7df3c71b)

Leaving bits uncleared set causes callbacks to be triggered even
though there are no events to process. Starting with D131160
we have a callback that makes blocking read calls over pipe which
was causing the lldb-server main loop to become unresponsive / blocked
on Android.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D144240

Don't merge invokes if this replaces constant operands with phis
in a place where this is not legal.

This also disallows converting operand bundles from constant to
non-constant, in line with the restriction we use in other
transforms.

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

Differential Revision: https://reviews.llvm.org/D146723

(cherry picked from commit 11313108)

When calling InitializeBase(...), TryOrBuidlParenListInit(...) needs to
pass in the parent entity; otherwise, we erroneously try to cast
CurContext to a CXXConstructorDecl[0], which can't be done since we're
performing aggregate initialization, not constructor initialization.

Field initialization is not affected, but this patch still adds some
tests for it.

Fixes 62296

[0]: https://github.com/llvm/llvm-project/blob/33d6bd1c667456f7f4a9d338a7996a30a3af50a3/clang/lib/Sema/SemaAccess.cpp#L1696

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D149301

MSVC link.exe added this flag and MS STL started using this flag in
.drectve [1] when compiling with Clang with asan enabled, as reported
on https://github.com/llvm/llvm-project/issues/56300. This causes issues
with lld-link because it rejects any unknown flags in .drective sections.

As dc07867d noted that, when using Clang
as the driver it explicitly passes the proper asan libraries. Therefore
it should be acceptable to ignore this flag in lld-link to at least
unbreak building with clang-cl and linking with lld-link.

[1]: https://github.com/microsoft/STL/blob/faaf094ee16bcbfb2c8d612fdb9334bcdef2fd0a/stl/inc/__msvc_sanitizer_annotate_container.hpp#L35

Differential Revision: https://reviews.llvm.org/D149023

(cherry picked from commit 8fa0cfeb)

This is a small QoL improvement suggested by FrancescElies in
https://github.com/llvm/llvm-project/issues/56300#issuecomment-1172104966.

Differential Revision: https://reviews.llvm.org/D149022

(cherry picked from commit 9b15e984)

If the removable definition resides in an INLINEASM_BR target, the
reuseable candidate might not dominate the INLINEASM_BR.

   bb0:
      INLINEASM_BR &"" %bb.1
      renamable $x8 = MOVi64imm 29273397577910035
      B %bb.2
      ...
    bb1:
      renamable $x8 = MOVi64imm 29273397577910035
      renamable $x8 = ADDXri killed renamable $x8, 2048, 0
    bb2:

Removing the second mov is a hazard when the inline asm branches to bb1.

Skip such replacements when the to be removed instruction is in the
target of such an INLINEASM_BR instruction.

We could get more aggressive about this in the future, but for now
simply abort.

This is causing a boot failure on linux-4.19.y branches of the LTS Linux
kernel for ARCH=arm64 with CONFIG_RANDOMIZE_BASE=y (KASLR) and
CONFIG_UNMAP_KERNEL_AT_EL0=y (KPTI).

Link: https://reviews.llvm.org/D123394
Link: https://github.com/ClangBuiltLinux/linux/issues/1837

Thanks to @nathanchance for the report, and @ardb for debugging.

Reviewed By: efriedma

Differential Revision: https://reviews.llvm.org/D149191

(cherry picked from commit 012ea747)

Demonstrates a hazard in machine-latecleanup.

Differential Revision: https://reviews.llvm.org/D149190

(cherry picked from commit 095a0c67)

[nd: remove isOutlined MIR key due to missing commit 267708f9
     ("[MachineOutliner] Add IsOutlined to MachineFunction")]

The fuzzer build was failing on armv7l, with an invalid triple
error. This happened because CMake's get_compiler_rt_target
function was missing some code to correctly handle arm archs,
such as armhf.

This was originaly part of https://reviews.llvm.org/D140011, that
landed on main with commit cd173cbd.

Fixes #60115

Differential Revision: https://reviews.llvm.org/D142906

The build of scudo was failing on armv7l, with undefined references
to unwinder symbols, such as __aeabi_unwind_cpp_pr0. These are
needed by RTGwpAsan and thus, on ARM, scudo must also be linked
against an unwind library.

The cmake command that caused the build failure was:

cmake --fresh -S "$PWD/llvm/" -B "$PWD/build/" -G Ninja \
  -DCMAKE_INSTALL_PREFIX="$PWD/install" \
  -DCMAKE_BUILD_TYPE=Release \
  -DLLVM_ENABLE_PROJECTS="clang;lld;lldb;clang-tools-extra;polly" \
  -DLLVM_ENABLE_RUNTIMES="compiler-rt;libcxx;libcxxabi;libunwind" \
  -DLLVM_TOOLCHAIN_TOOLS="llvm-ar;llvm-ranlib;llvm-objdump;\
llvm-rc;llvm-cvtres;llvm-nm;llvm-strings;llvm-readobj;\
llvm-dlltool;llvm-pdbutil;llvm-objcopy;llvm-strip;llvm-cov;\
llvm-profdata;llvm-addr2line;llvm-symbolizer;llvm-windres;llvm-ml;\
llvm-readelf;llvm-size" \
  -DLLVM_INSTALL_BINUTILS_SYMLINKS=OFF -DLLVM_PARALLEL_LINK_JOBS=1

Fixes #60115

Reviewed By: hctim

Differential Revision: https://reviews.llvm.org/D142888

(cherry picked from commit e1e97268)

There is a bug in the package tree of on the default images that
causes some dependencies not to be found.  Running apt-get gets us
the latest package lists rather than relying on the default lists
in the GitHub Runner imgae, which can be up to a week old.

Running apt-get update before intstalling packages is also recommended in
the official github documentation:

https://docs.github.com/en/actions/using-github-hosted-runners/customizing-github-hosted-runners#installing-software-on-ubuntu-runners

Reviewed By: thieta

Differential Revision: https://reviews.llvm.org/D148741

(cherry picked from commit 93d6289c)

Reviewed By: thieta

Differential Revision: https://reviews.llvm.org/D148772

(cherry picked from commit 74acaf18)

Adding this on behalf of yueh.ting.chen@gmail.com.

Reviewed By: thieta

Differential Revision: https://reviews.llvm.org/D148734

(cherry picked from commit cd397913)

After D138238 introduced the then/else blocks, we should remove UB-implying metadata for the promoted speculative instruction.

Reviewed By: nikic

Differential Revision: https://reviews.llvm.org/D148456

(cherry picked from commit 2832d794)

Resetting oucp's stack to zero in swapcontext interception is incorrect,
since it breaks ucp cleanup after swapcontext returns in some cases:

Say we have two contexts, A and B, and we swapcontext from A to B, do
some work on Bs stack and then swapcontext back from B to A. At this
point shadow memory of Bs stack is in arbitrary state, but since we
can't know whether B will ever swapcontext-ed to again we clean up it's
shadow memory, because otherwise it remains poisoned and blows in
completely unrelated places when heap-allocated memory of Bs context
gets reused later (see https://github.com/llvm/llvm-project/issues/58633
for example). swapcontext prototype is swapcontext(ucontext* oucp,
ucontext* ucp), so in this example A is oucp and B is ucp, and i refer
to the process of cleaning up Bs shadow memory as ucp cleanup.

About how it breaks:
Take the same example with A and B: when we swapcontext back from B to A
the oucp parameter of swapcontext is actually B, and current trunk
resets its stack in a way that it becomes "uncleanupable" later. It
works fine if we do A->B->A, but if we do A->B->A->B->A no cleanup is
performed for Bs stack after B "returns" to A second time. That's
exactly what happens in the test i provided, and it's actually a pretty
common real world scenario.

Instead of resetting oucp's we make use of uc_stack.ss_flags to mark
context as "cleanup-able" by storing stack specific hash. It should be
safe since this field is not used in [get|make|swap]context functions
and is hopefully never meaningfully used in real-world scenarios (and i
haven't seen any).

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

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D137654

(cherry picked from commit b380e8b6)

(cherry picked from commit 3248ca0d)

FileCheck is not very useful here.

(cherry picked from commit fd2cafbd)

These tests were failing on SystemZ hosts, I don't think JIT'ing non-SystemZ
modules on SystemZ is supported.

The tests were initiallay enabled on all arches by
7a761402.

Differential Revision: https://reviews.llvm.org/D145763

(cherry picked from commit e30ce634)

Reviewed By: kwk

Differential Revision: https://reviews.llvm.org/D143535

(cherry picked from commit 5b8156bf)

Function arguments or return values that are complex floating point values
aren't correctly lowered for Windows x86 32-bit and 64-bit targets.
See: https://github.com/llvm/llvm-project/issues/61976

Add targets that are specific for these platforms and OS.

With thanks to @mstorsjo for pointing out the fix.

Reviewed By: vzakhari

Differential Revision: https://reviews.llvm.org/D147768

(cherry picked from commit 774703ec)

Fixes #62161.

Differential Revision: https://reviews.llvm.org/D148447

(cherry picked from commit 2bcfff67)

This reverts commit 70de684d.

This causes a regression as described in #61785

(cherry picked from commit 104cd749)

https://reviews.llvm.org/rGd656ae28095726830f9beb8dbd4d69f5144ef821
introduced a additional checks before calling noreturn functions in
response to this security paper related to Catch Handler Oriented
Programming (CHOP):
https://download.vusec.net/papers/chop_ndss23.pdf
See also:
https://bugs.chromium.org/p/llvm/issues/detail?id=30

This causes stack canaries to be inserted in C code which was
unexpected; we noticed certain Linux kernel trees stopped booting after
this (in functions trying to initialize the stack canary itself).
https://github.com/ClangBuiltLinux/linux/issues/1815

There is no point checking the stack canary like this when exceptions
are disabled (-fno-exceptions or function is marked noexcept) or for C
code.  The GCC patch for this issue does something similar:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=a25982ada523689c8745d7fb4b1b93c8f5dab2e7

Android measured a 2% regression in RSS as a result of d656ae28 and
undid it globally:
https://android-review.googlesource.com/c/platform/build/soong/+/2524336

Reviewed By: xiangzhangllvm

Differential Revision: https://reviews.llvm.org/D147975

(cherry picked from commit fc4494df)

$ra should be restored before $a0, otherwise the baseaddress ($a0) would
be destroyed. See file `UnwindRegistersSave.S` for reference.

This also makes libcxx and libcxxabi regtest pass for the `-DLIBCXXABI_USE_LLVM_UNWINDER=ON` build.

Reviewed By: MaskRay, xen0n, #libunwind

Differential Revision: https://reviews.llvm.org/D147372

(cherry picked from commit ff0aabf1)

This is here for local unwinding, which unw_resume() restores
the machine state and then directly resumes execution in the
target stack frame.

Reviewed By: wangleiat

Differential Revision: https://reviews.llvm.org/D147371

(cherry picked from commit 366c5474)

This adds some basic handling for target(+crypto) attributes. In this patch it
just enabled aes and sha2 regardless of the architecture revision, which
matches gccs implementation (and keeps the patch simple).

Differential Revision: https://reviews.llvm.org/D142135

(cherry picked from commit 43aa293a)

The "preferred" buffer size for raw_ostream is set to BUFSIZ which on
Windows is only 512. This results in more calls to write and this
overhead can have a significant negative impact on performance,
especially when Anti-Virus is also involved.

Therefore increase the "preferred" buffer size to 16KB for Windows.

One example of where this helps is the LLD --Map option which dumps out
the symbol map for a link. In a link of UE4, this change has been seen
to improve the performance of the symbol map writing by more than a
factor of 6.

Differential Revision: https://reviews.llvm.org/D147340

(cherry picked from commit a3aa916d)

Summary:
This creates install-clang-linker-wrapper{,-stripped} targets which are
useful for Linux distro builds when using LLVM_DISTRIBUTION_COMPONENTS.

Fixes: https://bugs.archlinux.org/task/77814

Differential Revision: https://reviews.llvm.org/D145862

(cherry picked from commit c2aabcfc)