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)

We were accidentally issuing "static lambdas are incompatible with C++
standards before C++2b" with -pedantic because it was an ExtWarn
diagnostic rather than a Warning. This corrects the diagnostic category
and adds some test coverage.

Fixes #61582

(cherry picked from commit b904e68f)

Use proper relocation for aarch64

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

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

Previously, we would only pass the size parameter to the deallocation
function if the type is completely the same. But it is good enough to
make them unqualified the smae.

(cherry picked from commit d2b0b261)

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

(cherry picked from commit 3fe3f9c5)

(cherry picked from commit 78f17b2a)

Currently, libunwind just uses stxvd2x/lxvd2x to save/restore
VSX registers respectively. This puts the registers in
doubleword-reversed order into memory on little endian systems.
If both the save and restore are done the same way, this
isn't a problem. However if the unwinder is just restoring
a callee-saved register, it will restore it in the wrong
order (since function prologues save them in the correct order).
This patch adds the necessary swaps before the saves and after
the restores.

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

(cherry picked from commit 372820bf)

This fixes test failures on AArch64 with libgcc-13:

Clang :: Interpreter/global-dtor.cpp
Clang-Unit :: Interpreter/./ClangReplInterpreterTests/2/4

Reviewed By: lhames, v.g.vassilev

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

(cherry picked from commit 68c14f58)

When linking a shared library with Flang on MinGW, the functions from the
Flang runtime are exported from the shared library. When trying to link an
executable to that library using Flang, the linker errors out because the
functions from the runtime conflict with the functions exported from the
shared library.

Add the Flang runtime libraries to the list of libraries for which no
symbols are exported.

Reapplying the patch with the git author name corrected.

Reviewed By: mstorsjo

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

(cherry picked from commit 0ea8229b)

We were accidentally issuing "overloaded 'operator[]' with more than
one parameter is a C++2b extension" with -pedantic because it was an
ExtWarn diagnostic rather than a Warning. This corrects the diagnostic
category and adds some test coverage.

Fixes #61582

Add unwind_arm_ehabi.h and unwind_itanium.h to the unwind module and use angle includes to include them.

Reviewed By: ldionne, #libunwind

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

(cherry picked from commit 1187d8a6)

This patch fixes #60307 issue. The 8bb4451a introduces the possibility
to unite overlapped or adjacent address ranges to keep address ranges
in an unambiguous state. The AddressRangesMap is used to normalize
address ranges. The AddressRangesMap keeps address ranges and the value
of the relocated address. For intersected range, it creates a united
range that keeps the last inserted mapping value. The same for adjusted ranges.
While it is OK to use the last inserted mapping value for intersected ranges
(as there is no way how to resolve ambiguity) It is not OK to use the
last inserted value for adjacent address ranges. Currently, two following
address ranges are united into a single one:

{0,24,17e685c} {24,d8,55afe20} -> {0,d8,55afe20}

To avoid the problem, the AddressRangesMap should not unite adjacent address ranges
with different relocated addresses. Instead, it should leave adjacent address ranges
as separate ranges. So, the ranges should look like this:

{0,24,17e685c} {24,d8,55afe20}

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

(cherry picked from commit 1e72920c)

An #elif SANITIZER_SOLARIS clause was removed in D120048, but it also
removed the #else clause for the error fallback, causing the build to
fail on NetBSD.

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

(cherry picked from commit 8510cf9f)

Fixes PR#61384.

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

(cherry picked from commit 2ebbcfa0)

This patch adds a negative test for the issue discovered in D145930.

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

(cherry picked from commit d8c2a102)

Since FreeBSD 8 / 9 support was dropped from the Driver there is room to simplify
things with the ARM handling.

The exception model handling function can be removed.

EABI is now the default.

Reviewed By: dim

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

(cherry picked from commit 13a10e7e)

In the following example, we will end up hitting the `llvm_unreachable()`:
https://godbolt.org/z/5sccc95Ec
```lang=C++
enum class E {};
const E glob[] = {{}};
void initlistWithinInitlist() {
  clang_analyzer_dump(glob[0]); // crashes at loading from `glob[0]`
}
```

We should just return `std::nullopt` instead for these cases.
It's better than crashing.

Reviewed By: xazax.hun

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

(cherry picked from commit 558b46fd)

D138249 renamed a number of wasm intrinsics without implementing
auto-upgrade support.

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

(cherry picked from commit 6fc670e5)

Reviewed By: LuoYuanke
Differential Revision: https://reviews.llvm.org/D144163

(cherry picked from commit 96df79af)

GCC on AArch64 uses DW_CFA_GNU_NegateRAState for return address signing.

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

(cherry picked from commit 99211979)

This fixes unittest failures reported in D142279:
  flang-Unit :: Frontend/./FlangFrontendTests/5/7
  flang-Unit :: Frontend/./FlangFrontendTests/6/7

(cherry picked from commit e054e0da)

CheckDoConcurrentClauseRestriction and CheckTileClauseRestriction expect
that the construct has associated DoConstruct, while it is not set
when the do-loop has no loop control. The change is to skip the clauses
checks, when the do-loop does not have the loop control.

An alternative fix would be to associate the DoConstruct even when
the do-loop has no loop control and let Check*ClauseRestriction run their
checks, but I am not sure if associating invalid DoConstruct is a good idea.

This fixes failure in Semantics/OpenACC/acc-canonicalization-validity.f90
reported in D142279.

Reviewed By: clementval

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

(cherry picked from commit 02445263)

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

(cherry picked from commit 6772966d)

This is a follow up of D145550.

I think Reloc{Type,Symbol}{32,64} can keep unchanged as they are not
directly returning a field of the ELFRel[a] struct.

Reviewed By: DavidSpickett

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

(cherry picked from commit 27705f45)

According to `/usr/include/elf.h` and `lldb/source/Plugins/ObjectFile/ELF/ELFHeader.h`.
For ELF64 relocation, types of `offset` and `addend` should be `elf_addr` and `elf_sxword`.

Reviewed By: DavidSpickett

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

(cherry picked from commit 174a38f9)

Currently ApplyReloctions() deals with different archs' relocation types
together (in a single `switch() {..}`). I think it is incorrect because
different relocation types of different archs may have same enum values.

For example:
`R_LARCH_32` and `R_X86_64_64` are both `1`;
`R_LARCH_64` and `R_X86_64_PC32` are both `2`.

This patch handles each arch in seperate `switch()` to solve the enum
values conflict issue.

And a new test is added for LoongArch64.

Reviewed By: DavidSpickett

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

(cherry picked from commit c2c93873)