The lexer is overly permissive. When parsing file patterns in an input
section description and there is a missing `)`, we would accept many
non-sensible tokens (e.g. `}`) as patterns, leading to confusion, e.g.
`*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.text*)) } PROVIDE_HIDDEN(__code_end = .)`
(#81804).

Ideally, the lexer should be stateful to report more errors like GNU ld
and get rid of hacks like `ScriptLexer::maybeSplitExpr`, but that would
require a large rewrite of the lexer. For now, just reject certain
non-wildcard meta characters to detect common mistakes.

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

When debugging LLDB itself, it can often be useful to know the mangled
name of the function where a breakpoint is set. Since the `--verbose`
setting of `break --list` is aimed at debugging LLDB, this patch makes
it so that the mangled name is also printed in that mode.

Note about testing: since mangling is not the same on Windows and Linux,
the test refrains from hardcoding mangled names.

1. Change tests to use IR instead of -stats to avoid depending on Debug
mode
2. Add SkipInstrumentationRandomRate 
3. Remove HWASAN from stat strings

Reverts llvm/llvm-project#84174 due too sanitizer memory leak detection

In our analysis of guarding conditions, we were converting a-b == 0 into
a == b alternate form, but we were only checking for one of the two
forms for the sub. There's no requirement that the multiply only be on
the LHS of the add.

this gets checked in StackDepot::init anyway

We do not support GCC 4.8 anymore.

For GFX11.

Fix https://github.com/llvm/llvm-project/issues/83924.

FeatureDot11Insts (dot11-insts) for:
  v_dot4_f32_fp8_fp8, v_dot4_f32_fp8_bf8,
  v_dot4_f32_bf8_fp8, v_dot4_f32_bf8_bf8

was available. However, it turns out that the NVPTX compiler is not part
of every CUDA distribution, so `if_cuda_available` may evaluate to true
without that compiler being present, which breaks the build. This PR
thus sets the macro to 0 always (which was the behavior before #84007).

The implementation for from_chars in libcxx is possibly going to use our
decimal to float utilities, but to do that we need to support limiting
the length of the string to be parsed. This patch adds support for that
length limiting to decimal_exp_to_float, as well as the functions it
calls (high precision decimal, str to integer).

[clang][test] Add test for incompatible cv-qualified reference types in conversion function template (#81950)

We currently lack test coverage for
[SemaTemplateDeduction.cpp#L1619-L1620](https://github.com/llvm/llvm-project/blob/fe20a75/clang/lib/Sema/SemaTemplateDeduction.cpp#L1619-L1620),
which handles the case where both the P type and the A type are
reference types but A is more cv-qualified than P. This is deemed
non-deduced unless both A and P are possibly cv-qualified forms of the
template parameter T. This PR adds tests for that logic.

These tests highlight that we have missed oppurtunities proving
trip count bounds when our start/end values are sign extended
from smaller types and we have either a loop guard to relate our
start vs end, or a nsw/nuw fact to bound end.

This lets `transform.structured.convert_to_loops` return handles to the
generated loops, making this transformation more useful to use for
(transformation-)nesting purposes. This is modelled after SCFs
`transform.loop.forall_to_for` which returns handles to loops.

Introduced in commit aa2a96a2, with a
note that they might move out of the `Linalg`-Dialect, but no reason
given for the non-return of handles. As far as I can see, this transform
always returns loops.

DWP files don't usually have a GNU build ID built into them. When
searching for a .dwp file, don't require a UUID to be in the .dwp file.
The debug info search information was checking for a UUID in the .dwp
file when debug info search paths were being used. This is now fixed by
not specifying the UUID in the ModuleSpec being used for the .dwp file
search.

Build fix after (#84007).

glibc 2.39 added `nonnull` attribute to most libio functions accepting a
`FILE*` parameter, including fprintf[1]. The -fsanitize=undefined mode
checks the argument to fprintf and has extra counters, not expected by
two tests. Specify -fno-sanitize=nonnull-attribute to make the two tests
pass.

Fix #82883

[1]: https://sourceware.org/git/?p=glibc.git;a=commit;h=64b1a44183a3094672ed304532bedb9acc707554

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

This extends the work from 7755c261 to all of the different backend
taken count kinds that we print for the scev analysis printer.  As
before, the goal is to cut down on confusion as i4 -1 is a very
different (unsigned) value from i32 -1.

NFC.
Adds -strict-whitespace to RUN lines and adjusts CHECK line space
padding accordingly.

See also  (#84078)

Adds AMDGPU specific variadic MCExpr operations 'max' and 'or'.

Instead of generating a <1 x i1> active lane mask intrinsic, generate
the equivalent scalar ICMP instead. This allows us to avoid
unnecessarily extracting the scalar part from the vector mask.

Fixes llvm#73894.

This reverts commit 15b7b318.

This reverts commit 3ecd38c8.

This reverts commit b64482e2.

Not removing the malloc from earliest escape info leaves stale entries
in the cache.

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

PR: https://github.com/llvm/llvm-project/pull/84157

After 3ecd38c8, the Handler.getELFObjectFile routine is no
longer available.  Call ELF64LEObjectFile::create directly,
which should always be suitable for CUDA images.

The plugin was not getting built as the build_generic_elf64 macro
assumes the LLVM triple processor name matches the CMake processor name,
which is unfortunately not the case for SystemZ.

Fix this by providing two separate arguments instead.

Actually building the plugin exposed a number of other issues causing
various test failures. Specifically, I've had to add the SystemZ target
to
- CompilerInvocation::ParseLangArgs
- linkDevice in ClangLinuxWrapper.cpp
- OMPContext::OMPContext (to set the device_kind_cpu trait)
- LIBOMPTARGET_ALL_TARGETS in libomptarget/CMakeLists.txt
- a check_plugin_target call in libomptarget/src/CMakeLists.txt

Finally, I've had to set a number of test cases to UNSUPPORTED on
s390x-ibm-linux-gnu; all these tests were already marked as UNSUPPORTED
for x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu and are failing on
s390x for what seem to be the same reason.

In addition, this also requires support for BE ELF files in
plugins-nextgen: https://github.com/llvm/llvm-project/pull/83976

Code in plugins-nextgen reading ELF files is currently hard-coded to
assume a 64-bit little-endian ELF format. Unfortunately, this assumption
is even embedded in the interface between GlobalHandler and Utils/ELF
routines, which use ELF64LE types.

To fix this, I've refactored the interface to push all ELF specific
types into Utils/ELF. Specifically, this patch removes both the
getSymbol and getSymbolAddress routines and replaces them with a
single findSymbolInImage, which gets a StringRef identifying the
raw object file image as input, and returns a StringRef covering
the data addressed by the symbol (address and size) if found, or
std::nullopt otherwise.

This allows properly templating over multiple ELF format variants inside
Utils/ELF; specifically, this patch adds support for 64-bit big-endian
ELF files in addition to 64-bit little-endian files.

The full fold is one of the following:
1) `(fp_binop ({s|u}itofp x), ({s|u}itofp y))`
    -> `({s|u}itofp (int_binop x, y))`
2) `(fp_binop ({s|u}itofp x), FpC)`
    -> `({s|u}itofp (int_binop x, (fpto{s|u}i FpC)))`

And support the following binops:
    `fmul` -> `mul`
    `fadd` -> `add`
    `fsub` -> `sub`

Proofs: https://alive2.llvm.org/ce/z/zuacA8

The proofs timeout, so they must be reproduced locally.

Closes #82555