Fix #54456: `objcopy --only-keep-debug` produces a linked image with invalid
empty dynamic section. llvm-objdump -p currently reports an error which seems
excessive.

```
% llvm-readelf -l a.out
llvm-readelf: warning: 'a.out': no valid dynamic table was found
...
```

Follow the spirit of llvm-readelf -l (D64472) and report a warning instead.
This allows later files to be dumped despite warnings for an input file, and
improves objdump compatibility in that the exit code is now 0 instead of 1.

```
% llvm-objdump -p a.out  # new behavior
...
Program Header:
llvm-objdump: warning: 'a.out': invalid empty dynamic section
% objdump -p a.out
...
Dynamic Section:

```

Reviewed By: jhenderson, raj.khem

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

(cherry picked from commit 11a8fc68)

(cherry picked from commit 423af54c)

ComputePHILiveOutRegInfo assumes that constant incoming values to
Phis will be zero extended if they aren't a legal type. To guarantee
that we should zero_extend rather than any_extend constants.

This fixes a bug for RISCV where any_extend of constants can be
treated as a sign_extend.

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

(cherry picked from commit 4eb59f01)

The code that inserts AssertZExt based on predecessor information assumes
constants are zero extended for phi incoming values this allows
AssertZExt to be created in blocks consuming a Phi.
SelectionDAG::getNode treats any_extend of i32 constants as sext for RISCV.
The code that creates phi incoming values in the predecessors creates an
any_extend for the constants which then gets treated as a sext by getNode.
This makes the AssertZExt incorrect and can cause zexts to be
incorrectly removed.

This bug was introduced by D105918

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

(cherry picked from commit 268371cf)

The pointer.volatile.pass.cpp test was already marked as XFAIL for
mingw-dll (for reasons explained in the comment above it).

The same issue also appears in clang-cl-dll when built with newer
CMake versions. (It didn't appear with older versions of CMake, as
CMake built the library with the clang-cl flag `-std:c++latest` when
we've requested C++ 20 - which practically built it in c++2b mode with
current clang versions. With current versions of CMake, it passes
`-std:c++20` instead.)

As it succeeds/fails dependent on factors we don't
directly control, mark it as UNSUPPORTED instead of XFAIL.

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

(cherry picked from commit b048397d)

STB_GNU_UNIQUE should be treated in a way similar to STB_GLOBAL.
This fixes an "Invalid Binding" failure in an LLVM_ENABLE_ASSERTIONS=on build
for source files like glibc elf/tst-unique1mod1.c .

This bug has been benign so far because (a) Clang does not produce
%gnu_unique_object by itself (b) a non-assertion build likely picks the
STB_GLOBAL code path anyway.

(cherry picked from commit 6bdad85b)

After D108936, @llvm.smul.with.overflow.i64 was lowered to __multi3
instead of __mulodi4, which also doesn't exist on PowerPC 32-bit, not
even with compiler-rt. Block it as well so that we get inline code.

Because libgcc doesn't have __muloti4, we block that as well.

Fixes #54460.

Reviewed By: craig.topper

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

The solution using append was reported not to work, but additionally it
would use the contents of the checked-out source tree instead of the git
tag or commit. This uses `git archive`, so it will use the right commit,
and at least for me (with GNU tar) it seems to work as intended.

Should fix #53281.

Reviewed By: kwk

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

(cherry picked from commit 3a33664e)

Reviewed By: ldionne

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

(cherry picked from commit 6e2c6c9d)

The generated arm_neon.h header isn't -Wdeclaration-after-statement
compliant when targeting -mbig-endian. Update the generator to declare
the return value, if any, first before any other arguments that might
need to be "reversed" from little endian to big.

Another approach would have been to try to ignore this warning in system
headers, though that might not be precise for tokens involved in macro
expansion. See also: https://reviews.llvm.org/D116833#3236209.

Link: https://github.com/ClangBuiltLinux/linux/issues/1603
Fixes: https://github.com/llvm/llvm-project/issues/54062

Reviewed By: DavidSpickett

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

(cherry picked from commit 5a2e56b7)

Arm is not quite ready for unwinding yet.

(cherry picked from commit 9abeb80e)

Use "operands" instead of "operators"

Closes #54397

(cherry picked from commit 114a8903)

This is a re-commit of 98fd3b35.  The
newly added test was failing on the bots, and I've fixed the test now so
that it doesn't actually invoke the linker.

(cherry picked from commit fed96f31)

Merge the llvm, clang, and libclc tests into a single job.  This is the
most sub-projects we can test at once without running out of disk space
on the GitHub runners.

Reviewed By: thieta

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

See https://reviews.llvm.org/D121626 for details -- this re-enables the
CTAD we removed, since it does break some stuff as well (even though it's
not nearly as bad as the removed constructors fixed by D121626).

(cherry picked from commit 6a7f0551)

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

Back in 3a208c68, we implemented the range-based constructor for <span>.
However, in doing so, we removed a previous non-standard constructor that
we provided before shipping <ranges>. Unfortunately, that breaks code that
was relying on a range-based constructor until we ship all of <ranges>.

This patch reintroduces the old non-conforming constructors and tests
that were removed in 3a208c68 and uses them whenever <ranges> is
not provided (e.g. in LLVM 14). This is only a temporary workaround
until we enable <ranges> by default in C++20, which should hopefully
happen by LLVM 15.

The goal is to cherry-pick this workaround back to the LLVM 14 release
branch, since I suspect the constructor removal may otherwise cause
breakage out there, like the breakage I saw internally.

We could have avoided this situation by waiting for C++20 to be finalized
before shipping std::span. For example, we could have guarded it with
something like _LIBCPP_HAS_NO_INCOMPLETE_RANGES to prevent users from
accidentally starting to depend on it before it is stable. We did not
have these mechanisms when std::span was first implemented, though.

NOTE: This is a pretty modified version of d4c39f1a since that one
didn't apply properly onto the release/14.x branch.

(cherry picked from commit d4c39f1a)

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

(cherry picked from commit 7403c02f)

This reverts commit e54a7bf0.

There was a bug reported with this patch, see: https://reviews.llvm.org/D121276#3375464

This reverts commit a9415df3.

There are still bugs reported with the new bootstraping build.
See https://reviews.llvm.org/D121276#3375464

This reverts commit 27712337.

There are still some issues with this change to be worked out, so revert
this patch to avoid having to change ABIs from LLVM 13->14 and then again from
LLVM 14->15.  See discussion in https://reviews.llvm.org/D118511

This reverts commit eb84577c.

The issues with check-all were fixed in e54a7bf0,
so we can re-enable bootstrap build for test-release.sh.

Prior to this change, we would make check-all depend on check-runtimes
which is a target that runs tests in the runtimes build. This means that
the runtimes tests are going to run prior to other test suites in
check-all, and if one of them fails, we won't run the other test suites
at all.

To address this issue, we instead collect the list of test suites and
their dependencies from the runtimes subbuild, and include them in
check-all, so a failure of runtimes test suite doesn't prevent other
test suites from being executed.

This addresses https://github.com/llvm/llvm-project/issues/54154.

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

(cherry picked from commit f39a971d)

When building libcxxabi via LLVM_ENABLE_RUNTIMES=libcxxabi the CMake
invocation fails because of missing "unwind" target.  However,
if the extraneous dependency is removed, the library builds just fine
against installed libunwind and tests work fine.  To fix this,
add the dependency only if the target actually exists.

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

(cherry picked from commit 5244ef0f)

We were using:
armv8-linux-gnueabihf
But for a native clang build the default target is:
armv8l-linux-gnueabihf

(ditto for v7)

Add the "l" to the target triples and update the one test
that is unsupported to look for the various possible names.

armv(7 or 8)(m or l, optionally)

The UNSUPPORTED does not include aarch64 because aarch64 Linux
(and others that follow Arm's AAPCS64) use quad precision for
long double where arm64 (darwin) does not:
https://developer.apple.com/documentation/xcode/writing-arm64-code-for-apple-platforms
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#811arithmetic-types

Reviewed By: rovka

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

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

(cherry picked from commit 0bff3a96)

This reverts commit c8bb1777 to fix
https://github.com/llvm/llvm-project/issues/54154 on the release branch.

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

Fix checking for an unsupported stdlib++.

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

(cherry picked from commit 5b7941ad)

[SimplifyCFG][PhaseOrdering] Defer lowering switch into an integer range comparison and branch until after at least the IPSCCP

That transformation is lossy, as discussed in
https://github.com/llvm/llvm-project/issues/53853
and https://github.com/rust-lang/rust/issues/85133#issuecomment-904185574

This is an alternative to D119839,
which would add a limited IPSCCP into SimplifyCFG.

Unlike lowering switch to lookup, we still want this transformation
to happen relatively early, but after giving a chance for the things
like CVP to do their thing. It seems like deferring it just until
the IPSCCP is enough for the tests at hand, but perhaps we need to
be more aggressive and disable it until CVP.

Fixes https://github.com/llvm/llvm-project/issues/53853
Refs. https://github.com/rust-lang/rust/issues/85133

Reviewed By: nikic

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

Based on original tests from D119839.

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

Introduce a new attribute "function-inline-cost-multiplier" which
multiplies the inline cost of a call site (or all calls to a callee) by
the multiplier.

When processing the list of calls created by inlining, check each call
to see if the new call's callee is in the same SCC as the original
callee. If so, set the "function-inline-cost-multiplier" attribute of
the new call site to double the original call site's attribute value.
This does not happen when the original call site is intra-SCC.

This is an alternative to D120584, which marks the call sites as
noinline.

Hopefully fixes PR45253.

Reviewed By: davidxl

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

(cherry picked from commit 53e5e586)

Remove the dependency on ounit2 and the relevant lit code.  It seems
that ounit2 is not used at all and all OCaml binding tests pass without
it installed.

Thanks for Shiwei Weng and Josh Berdine for bringing this to
my attention.

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

(cherry picked from commit 2c5c243b)

LICM will speculatively hoist code outside of loops. This requires removing information, like alias analysis (https://github.com/llvm/llvm-project/issues/53794), range information (https://bugs.llvm.org/show_bug.cgi?id=50550), among others. Prior to https://reviews.llvm.org/D99249 , LICM would only be run after LoopRotate. Running Loop Rotate prior to LICM prevents a instruction hoist from being speculative, if it was conditionally executed by the iteration (as is commonly emitted by clang and other frontends). Adding the additional LICM pass first, however, forces all of these instructions to be considered speculative, even if they are not speculative after LoopRotate. This destroys information, resulting in performance losses for discarding this additional information.

This PR modifies LICM to accept a ``speculative'' parameter which allows LICM to be set to perform information-loss speculative hoists or not. Phase ordering is then modified to not perform the information-losing speculative hoists until after loop rotate is performed, preserving this additional information.

Reviewed By: lebedev.ri

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

(cherry picked from commit d9da6a53)

(cherry picked from commit 07cf9594)

(cherry picked from commit a5b9987a)

(cherry picked from commit 73ee8287)

This is an alternative to D120330, which disables MachineSink for
functions with irreducible cycles entirely. This avoids both the
correctness problem, and ensures we don't perform non-profitable
sinks into cycles. At the same time, it may also disable
profitable sinks in the same function. This can be made more
precise by using MachineCycleInfo in the future.

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

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

(cherry picked from commit 6fde0439)

(cherry picked from commit e075bf6b)

Remove `TYPE BIN` parameter that is introduced in CMake 3.14 and revert back to
the equivalent compatible form `DESTINATION ${CMAKE_INSTALL_BINDIR}`.

Addresses https://github.com/llvm/llvm-project/issues/54099

Reviewed By: rafauler

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

(cherry picked from commit 018ad03e)