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)

Reported https://lab.llvm.org/buildbot/#/builders/5/builds/32113

(cherry picked from commit ea4cbbbf)

Integrate the BranchRelaxation pass to help with relaxing out-of-range
conditional branches.

This is mostly of concern for SPARCv9, which uses conditional branches with
much smaller range than its v8 counterparts.
(Some large autogenerated code, such as the ones generated by TableGen, already
hits this limitation when building in Release)

Reviewed By: arsenm

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

(cherry picked from commit 24e30019)

SROA may convert a wide integer load into a narrow pointer load,
make sure we don't crash. It would not be legal to transfer the
metadata in this case.

(cherry picked from commit fc6e91fe)

Related to a02c3af9. Fixes #61700.

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

(cherry picked from commit 767aee1d)

This DAG combine is correct on little endian targets but
is incorrect on big endian targets.
Add big endian code to correct it.

Differential revision: https://reviews.llvm.org/D146460

This was the original option name from the first iteration of the patch
that added the feature, but during review, a different name was suggested
and preferred - but the reference in the helpful message was missed.

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

(cherry picked from commit 014e5c8d)

In some cases, there's no adjacent executable named "clang" or
"clang-cl", but one name "clang-<major>". This logic doesn't
cover every possible deployment setup of course, but should
cover more fairly common/reasonable cases.

See
https://github.com/curl/curl-for-win/commit/caaae171ac43af5b883403714dafd42030d8de61#commitcomment-105808524
for discussion about a case where this would have been helpful.

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

(cherry picked from commit 282744a9)

The arguments passed in this option were passed onto the child
process, but we still blindly used the clang binary that we had
found to sys::ExecuteAndWait as the intended executable to run.

If the user hasn't specified any custom --preprocessor command,
Args[0] is equal to the variable Clang.

This doesn't affect any tests, since the tests only print the
arguments it would try to execute (but not the first parameter to
sys::ExecuteAndWait), but there's no testes for executing it
(and validating that it did execute the right thing).

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

(cherry picked from commit d2fa6b69)

AppleClang 1403 has some bugs that prevent std::source_location from
working properly on it. Consequently, we XFAILed the unit test for
source_location with that compiler. However, we should also avoid
advertising that the feature is supported on that compiler, otherwise
our feature-test macros lie. This was noticed to break Boost.Asio
when building with a recent libc++ and AppleClang 14.0.3.

rdar://106863087

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

(cherry picked from commit c2a42381)

As discussed earlier in the [GitHub
issue](https://github.com/llvm/llvm-project/issues/59500), currently
LLVM generates invalid code when emulated TLS is used. There were
attempts to resolve this previously (D102527), but they were not merged
because the component owners raised concerns about emulated TLS
efficiency.

The current state of the art is that:

- OpenBSD team, which raised the initial issue, simply has [patches
  downstream](https://github.com/openbsd/src/blob/a0747c9/gnu/llvm/llvm/lib/Target/RISCV/RISCVISelLowering.cpp#L2850-L2852).
- Our team, which raised the GH issue, has patches downstream as well.
  We also do not use `malloc` or any [dynamic
allocations](https://github.com/llvm/llvm-project/issues/59500#issuecomment-1349046835)
with emulated TLS, so the concerns raised in the original issue does not
apply to us.
- GCC compatibility is broken, because GCC supports emulated TLS.
- RISC-V is the only architecture in LLVM that does not support emulated
  TLS, and work is being done to at least warn the users about it
(D143619).

With all these in mind I believe it is important to address the
consumers' needs especially given that there is little to no maintenance
downsides.

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

(cherry picked from commit f5e63f8f)

Closes #61209.

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

(cherry picked from commit 253985d5)

Fixes a bug in IntegerLiteralSeparatorFixer::checkSeparator() so that
only unformatted integer literals will be formatted.

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

(cherry picked from commit 5b5c49ad)

This Moves ELFObjectFile to using
RISCVISAInfo::parseNormalizedArchString which does not ignore or produce
an error for ISA extensions with a version that isn't
recognised/supported by LLVM. As current GCC is marking its objects with
a higher version of the A, F, and D extensions than LLVM (see [extension
versioning
discussion](https://discourse.llvm.org/t/rfc-resolving-issues-related-to-extension-versioning-in-risc-v/68472)
this massively improves the usability of llvm-objdump with such
binaries.

This patch is functionally a cherry-pick of
af602edf and
91c6174c, though I've constructed the
backport manually because other changes unrelated to this specific fix
make a direct cherry pick difficult.

This reverts commit 56edf062.

This change modified the public API/ABI which is not allowed in stable releases.

As stated in https://github.com/llvm/llvm-project/issues/61685, by
passing LLD the import lib of the asan DLL first, the asan DLL will be
listed as the first entry in the Import Directory Table, making it be
loaded first before other user DLLs. This allows asan to be initialized
as early as possible to increase its instrumentation coverage to include
other DLLs not built with asan.

This also avoids some false asan reports on `realloc` for memory
allocated during initialization of user DLLs being loaded earlier than
asan, because after this change they will be loaded later than asan.

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

(cherry picked from commit 81358e91)

ARMFrameLowering.cpp - fix MSVC "result of 32-bit shift implicitly converted to 64 bits" warning. NFC.

(cherry picked from commit b2061453)

This fixes compiling some uncommon cases.

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

(cherry picked from commit c5383536)

(cherry picked from commit f50cad2c)

Part of the bitset sort optimization can cause code using an invalid
comparator to go out-of-bounds, which is potentially dangerous. This
was an unintended consequence of the original patch, or at least the
fact that we didn't have anything in place to catch that or announce
that to vendors was unintended.

More specifically, std::sort assumes that the comparison predicate is a
strict weak order (which is a pre-condition to the algorithm). However,
in practice, some predicates may not satisfy the pre-condition in subtle
ways. While that is technically a user problem, we need a good answer
for how to handle this given that we know this exists in the wild and
unconditionally reading out-of-bounds data is not a great answer. We
can't weaken the preconditions of the algorithm, however letting this
situation happen without even a way of diagnosing the issue is pretty bad.

Hence, this patch reverts the optimization from release/16.x so that we
can buy a bit of time to figure out how to properly handle and communicate
this change in the LLVM 17 release.

The bitset sort optimization was 4eddbf9f (aka https://llvm.org/D122780).
This patch is not a pure revert of the patch, I also fixed up the includes
a bit.

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

This patch is aimed directly at release/16.x -- it ensures that we
can run the CI successfully on the release branch. It's a collection
of changes that were made on main and not backported to release/16.x
because the CI had been failing since we created the branch.

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

Also, handle imaginary numbers, i.e., those with suffixes starting
with an 'i'.

Fixes #61676.

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

(cherry picked from commit 4d21868b)

When LLVM_NATIVE_TOOL_DIR was introduced in
d3da9067 / D131052, it consisted
of refactoring a couple cases of manual logic for tools in
clang-tools-extra/clang-tidy, clang-tools-extra/pseudo/include
and mlir/tools/mlir-linalg-ods-gen. The former two had the same
consistent behaviour while the latter was slightly different, so
the refactoring would end up slightly adjusting one or the other.

The difference was that the clang-tools-extra tools respected the
external variable for setting the tool name, regardless of the
LLVM_USE_HOST_TOOLS variable, while mlir-linalg-ods-gen tool
only checked its external variable if LLVM_USE_HOST_TOOLS was set.

LLVM_USE_HOST_TOOLS is supposed to be enabled automatically whenever
cross compiling, so this shouldn't have been an issue.

In https://github.com/llvm/llvm-project/issues/60784, it seems like
some users do cross compile LLVM, without CMake knowing about it
(without CMAKE_CROSSCOMPILING being set). In these cases, their
build broke, as the variables for pointing to external host tools
no longer were being respected.

The fact that CMAKE_CROSSCOMPILING wasn't set stems from a
non-obvious behaviour of CMake; CMAKE_CROSSCOMPILING isn't supposed
to be set by the user (and if it was, it gets overridden), but one
has to set CMAKE_SYSTEM_NAME to indicate that one is cross compiling,
even if the target OS is the same as the current host.

Skip the checks for LLVM_USE_HOST_TOOLS and always respect the
variables for pointing to external tools (both the old tool specific
variables, and the new LLVM_NATIVE_TOOL_DIR), if they're set. This
makes the logic within setup_host_tool more exactly match the
logic for the clang-tools-extra tools from before the refactoring
in d3da9067. This makes the behaviour
consistent with that of the tablegen executables, which also respect
the externally set variables regardless of LLVM_USE_HOST_TOOLS.

This fixes
https://github.com/llvm/llvm-project/issues/60784.

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

(cherry picked from commit 4a5bc791)

Commit cc2457ca changed the default but forgot to update the help message.

(cherry picked from commit 3d65cd40)

When `llvm-symbolizer.exe` is on the PATH in an entry containing two
consecutive backslashes, sanitizers will try to launch llvm-symbolizer
with its absolute path containing these consecutive backslashes. This
fails a sanity check in `sanitizer_symbolizer_win.cpp`.

According to the documentation of `CommandLineToArgvW` [1] and a MS blog
post [2], backslashes in general, regardless of how many of them in a
row, do not have any special effect, unless when immediately followed by
a double quote.

There already exists a check that fails when the command line arguments
contains double quote, therefore the check for double backslashes can
simply be removed.

[1]: https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-commandlinetoargvw
[2]: https://learn.microsoft.com/en-us/archive/blogs/twistylittlepassagesallalike/everyone-quotes-command-line-arguments-the-wrong-way

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

(cherry picked from commit b1871ceb)

We need to search referenced section based on relocations symbol section
to properly match end section symbols. For example on some binaries we
can observe that init_array_end/fini_array_end might be "placed" in to
the gap and since no section could be found for address the relocation
would be skipped resulting in wrong ADRP imm after emitting new text
resulting in binary sigsegv.

Credits for the test to Vladislav Khmelevskii aka yota9.

(cherry picked from commit 0776fc32)

Having an ODR violation with `__exception_guard` seems to be problematic in LTO builds. To avoid the ODR violation, give the class different names for exception/no-exceptions mode and have an alias to the correct class.

Reviewed By: ldionne, #libc, alexfh

Spies: aeubanks, dblaikie, joanahalili, alexfh, rupprecht, libcxx-commits

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

(cherry picked from commit 1a17739d)

Avoid replacing one adr instruction with two adrp+add by utilizing linker-provided nops
when they are present. By doing so we preserve relative offsets of next instructions
in a function which reduces chances to break undetected jump tables. This commit makes
release-mode lld-linked clang, lld and etc work after BOLT.

Reviewed By: rafauler, yota9

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

Old code breaks build with libstdc++ with assertions. Fix it.

(cherry picked from commit 7768f63e)

D132262 tried to simplify `IsMetadataOrEHFrameSection` originally introduced in
D127549 but caused a regression as `.quad` directives in

```
.section .note,"a",@note; note:
.quad extern-note    # extern is undefined

.section .rodata,"a",@progbits; rodata:
.quad extern-rodata  # extern is undefined

.section .nonalloc,"",@progbits; nw:
.quad extern-nw
```

are incorrectly rejected: these differences may be link-time constants and
are allowed in GNU assembler and LLVM MC's non-RISC-V ports.

Relax the conditions to allow these cases. For A-B, A may be defined later, but
this requiresFixups call has to eagerly make a decision. For now, emit ADD/SUB
unless A is `.L*`. This euristic handles many temporary label differences for
.debug_* and .apple_types sections. Ideally we should delay the decision of
PC-relative vs ADD/SUB until A is defined.

Reviewed By: compnerd

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

(cherry picked from commit 2f5fe16e)

(cherry picked from commit c598828b)

(cherry picked from commit feb3432a)

(cherry picked from commit 97f6283c)

(cherry picked from commit ffdd5a33)

Sometimes, symbols are present that point to the end of a section (i.e.,
one-past the highest valid address). Currently, BOLT either rejects
those symbols when they don't point to another existing section, or errs
when they do and the other section is not executable. I suppose BOLT
would accept the symbol when it points to an executable section.

In any case, these symbols should not be considered while discovering
functions and should not result in an error. This patch implements that.

Note that this patch checks explicitly for symbols whose value equals
the end of their section. It might make more sense to verify that the
symbol's value is within [section start, section end). However, I'm not
sure if this could every happen *and* its value does not equal the end.

Another way to implement this is to verify that the BinarySection we
find at the symbol's address actually corresponds to the symbol's
section. I'm not sure what the best approach is so feedback is welcome.

Reviewed By: yota9, rafauler

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

(cherry picked from commit 54ab9541)