Patch also includes a minor fix to AArch64::isLegalAddressingMode
to ensure all scalable types have a suitable bailout.

The subtarget was unconditionally reporting that SVE was to be used to
lower vectors when Neon was unavailable, even when SVE itself was
unavailable. This decision leads other parts of the compiler to crash,
e.g., when querying SVE vector sizes.

Reviewed By: sdesmalen

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

(cherry picked from commit c058eb99)

Previously when objcopy generated section headers, it padded the LEB
that encodes the section size out to 5 bytes, matching the behavior of
clang. This is correct, but results in a binary that differs from the
input. This can sometimes have undesirable consequences (e.g. breaking
source maps).

This change makes the object reader remember the size of the LEB
encoding in the section header, so that llvm-objcopy can reproduce it
exactly. For sections not read from an object file (e.g. that
llvm-objcopy is adding itself), pad to 5 bytes.

Reviewed By: jhenderson

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

(cherry picked from commit 1b21067c)

FRINT was added to matchRoundingOp after this function was written.
So FRINT was not tested originally.

For vectors, folding this causes us to create a CSR swap that tries
to write 7 to FRM. This is an illegal value and will cause the CSR
write to fail.

While this might be a legal fold we could do, I'm disabling it for
now so we can backport to LLVM 17 with the least risk.

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

(cherry picked from commit 2df9328f)

Relative to the previous attempt, this also adjusts RegionInfo
verification to allow unreachable predecessors.

-----

If a block in the CHR region has an unreachable predecessor, then
there will be no edge from that predecessor to the newly cloned
block. However, a phi node entry for it will be left behind. Make
sure that these incoming blocks get dropped as well.

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

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

(cherry picked from commit 7e2f1ae7)

This reverts commit 985486dc.

This seems to cause malformed profdata: crbug.com/1469456

(cherry picked from commit 4b08be77)

I don't have a test case for this but noticed this warning when including system headers with `-I` rather than `-isystem`.

```
In file included from <built-in>:1:
In file included from /nix/store/jq6bpm0xmhnbffhs5rkxq4n88g5xi2zg-clang-wrapper-11.0.1/resource-root/include/__clang_cuda_runtime_wrapper.h:157:
/nix/store/jq6bpm0xmhnbffhs5rkxq4n88g5xi2zg-clang-wrapper-11.0.1/resource-root/include/__clang_cuda_math.h:39:25: warning: extra tokens at end of #ifdef directive [-Wextra-tokens]
                        ^
```

Reviewed By: tra

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

(cherry picked from commit c49142e4)

In a standalone build, there is no guarantee that flang code would be
saved in a directory named flang. Check only the path under flang's root
directory.

Reviewed By: #flang, kiranchandramohan

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

(cherry picked from commit 94f377d8)

An empty struct is handled as a struct with a dummy i8, on all targets.

Most targets treat an empty struct return value as essentially
void - but some don't. (Currently, at least x86_64-windows-* and
powerpc64le-* don't treat it as void.)

When intializing a struct with such a no_unique_address member,
make sure we don't write the dummy i8 into the struct where there's
no space allocated for it.

Previously it would clobber the actual valid data of the struct.

Fixes https://github.com/llvm/llvm-project/issues/64253, and
possibly https://github.com/llvm/llvm-project/issues/64077
and https://github.com/llvm/llvm-project/issues/64427 as well.

We should omit the store for any empty record (not only ones
declared with no_unique_address); we can have a situation where a
class doesn't have the no_unique_address attribute, but is embedded
in an outer struct with the no_unique_address attribute - like this:

    struct S {};
    S f();
    struct S2 : public S { S2();};
    S2::S2() : S(f()) {}
    struct S3 { int x; [[no_unique_address]] S2 y; S3(); };
    S3::S3() : x(1), y() {}

Here, the problematic store (which this patch omits) is in
the constructor of S2. In the case of S3, S2 has no valid storage
and aliases x - thus the constructor of S2 should omit the dummy
store.

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

(cherry picked from commit d60c3d08)

Check iterator validity before use; fixes a crash seen in the RISC-V
Zcmp Push/Pop optimization pass when compiling an internal benchmark.

Reviewed By: asb, wangpc

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

(cherry picked from commit 53e89f5e)

This adds a RISC-V special case to ToolChain::GetDefaultDwarfVersion,
affecting Linux/Haiku/RISCVToolChain.

DWARF v5 .debug_loclists/.debug_rnglists's
DW_LLE_offset_pair/DW_RLE_offset_pair entry kinds utilitize `.uleb128 A-B`
directives where A and B reference local labels in code sections.
When A and B are separated by a RISC-V linker-relaxable instruction,
A-B is incorrectly folded without a relocation, causing incorrect debug
information.

```
void ext(void);
int foo(int x) {ext(); return 0;}
// DW_AT_location [DW_FORM_loclistx] of a DW_TAG_formal_parameter references a DW_LLE_offset_pair that can be incorrect after linker relaxation.

int ext(void);
void foo() { {
  int ret = ext();
  if (__builtin_expect(ret, 0))
    ext();
} }
// DW_AT_ranges [DW_FORM_rnglistx] of a DW_TAG_lexical_block references a DW_RLE_offset_pair that can be incorrect after linker relaxation.
```

D157657 will implement R_RISCV_SET_ULEB128/R_RISCV_SUB_ULEB128
relocations, fixing the issue, but the relocation is only supported by
bleeding-edge binutils 2.41 and not by lld/ELF yet.

The goal is to make the emitted DWARF correct after linking.
Many users don't care about the default DWARF version, but a linker
error will be unacceptable. Let's just downgrade the default DWARF
version, before binutils>=2.41 is more widely available.

An alternative compatibility option is to add a toggle to DwarfDebug.cpp,
but that doesn't seem like a good idea.

Reviewed By: asb, kito-cheng

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

(cherry picked from commit bbc0f99f)
(with a release note)

Fix crash when diagnostic is emit with invalid location,
but with attached valid ranges. Diagnostic can contain
invalid location, but SourceManager attached to it still
can be valid, use it in such case or fallback to known
SourceManager.

Fixes: #64602

Reviewed By: aaron.ballman

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

(cherry picked from commit efd44f80)

This reverts commit d031ff38.
See https://reviews.llvm.org/D154503#4576393 for a reproducer and
details.

(cherry picked from commit 7d259b36)

This issue was raised on https://github.com/llvm/llvm-project/issues/64268.

`flang/lib/Optimizer/Transforms/SimplifyIntrinsics.cpp` includes
`flang/Optimizer/HLFIR/HLFIRDialect.h` and might fails if the HLFIR related
tablegen files have not been generated.

Reviewed By: vzakhari

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

(cherry picked from commit 103907bc)

D141386 changed the semantics of !range metadata to return poison
on violation. If !range is combined with !noundef, violation is
immediate UB instead, matching the old semantics.

In theory, these IR semantics should also carry over into SDAG.
In practice, DAGCombine has at least one key transform that is
invalid in the presence of poison, namely the conversion of logical
and/or to bitwise and/or (https://github.com/llvm/llvm-project/blob/c7b537bf0923df05254f9fa4722b298eb8f4790d/llvm/lib/CodeGen/SelectionDAG/DAGCombiner.cpp#L11252).
Ideally, we would fix this transform, but this will require
substantial work to avoid codegen regressions.

In the meantime, avoid transferring !range metadata without
!noundef, effectively restoring the old !range metadata semantics
on the SDAG layer.

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

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

(cherry picked from commit 9deee6bf)

(cherry picked from commit 59d558a3)

The function changeVectorElementType assumes MVT input types will
result in MVT output types.  There's no gurantee this is possible
during early code generation and so this patch converts an instance
used during initial DAG construction to instead explicitly create a
new EVT.

NOTE: I could have added more MVTs, but that seemed unscalable as
you can either have MVTs with 100% element count coverage or 100%
bitwidth coverage, but not both.

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

(cherry picked from commit b7e6e568)

This reverts commit 8981520b.

See discussion in https://github.com/llvm/llvm-project/issues/64225

Differential https://reviews.llvm.org/D145477 removed the check for `(yaml and args.export_fixes)` in line 303 to skip looking for the `clang-apply-replacements` binary. However, the `tmpdir` variable was set in this true branch when exporting fixes and therefore is `None` when invoking run-clang-tidy with `run-clang-tidy -p . -export-fixes fixes.yaml`.

Reviewed By: PiotrZSL

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

(cherry picked from commit c3da9927)

When compiling Rust code we may end up with calls to functions provided
by other code units. Presently this code crashes on a null pointer
dereference - this patch avoids that crash and adds a test.

Reviewed By: ast

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

(cherry picked from commit 055893be)

This was an oversight when the GFX11 early release VGPRs optimization
was reimplemented in D153279.

Sending the DEALLOC_VGPRS message is a performance optimization so there
is no need to do it at -O0. In addition it makes some kinds of post
mortem debugging hard or impossible, since VGPR values are no longer
available to inspect at the s_endpgm instruction.

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

(cherry picked from commit 3091bdb8)

We need unsigned integer here.

Fixes #64534

Reviewed By: eopXD

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

(cherry picked from commit 5a3753f3)

Since GCC 11, the bundled Solaris/SPARC GCC uses the `sparcv8plus`
subdirectory for 32-bit objects, just like upstream GCC.  Before that, it
used `32` instead from a local patch.

Since `clang` doesn't know about that `sparcv8plus` subdirectory, it
wouldn't properly use GCC 11+ installations.

The new `solaris-sparc-gcc-search.test` testcase wasn't run initially (like
the existing `crash-report-null.test`) because the `.test` suffix wasn't
handled.

Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.

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

(cherry picked from commit 43dfe0f0)

* 4d494e76: Handle static_assert messages with an expression started by a literal
* 49e0495f Produce a warning instead of an error in unevaluated strings before C++26

Emiting an error on unexpected encoding prefix - which was allowed before C++26 -
caused build errors for a few users.
This downgrade the error to a warning on older language modes and C

`R_LARCH_PCREL20_S2` is a new added relocation type in LoongArch ELF
psABI v2.10 [1] which is not corvered by D138135 except `R_LARCH_64_PCREL`.

A motivation to support `R_LARCH_PCREL20_S2` in lld is to build the
runtime of .NET core (a.k.a `CoreCLR`) in which strict PC-relative
semantics need to be guaranteed [2]. The normal `pcalau12i + addi.d`
approach doesn't work because the code will be copied to other places
with different "page" and offsets. To achieve this, we can use `pcaddi`
with explicit `R_LARCH_PCREL20_S2` reloc to address +-2MB PC-relative
range with 4-bytes aligned.

[1]: https://github.com/loongson/la-abi-specs/releases/tag/v2.10
[2]: https://github.com/dotnet/runtime/blob/release/7.0/src/coreclr/vm/loongarch64/asmhelpers.S#L307

Reviewed By: xen0n, MaskRay

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

(cherry picked from commit 8a31f7dd)

When generating unwind tables for code which uses return-address
signing, we need to toggle the RA_SIGN_STATE DWARF register around any
tail-calls, because these require the return address to be authenticated
before the call, and could throw an exception. This is done using the
.cfi_negate_ra_state directive before the call, and .cfi_restore_state
at the start of the next basic block.

However, since D153098, the .cfi_restore_state isn't being inserted,
because the CFIFixup pass isn't being run. This re-enables that pass
when return-adress signing is enabled.

Reviewed By: ikudrin, MaskRay

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

(cherry picked from commit f2e7285b)

Using implicit CHECK prefix in one FileCheck invocation and explicit
CHECK-V83A in the other one seems to misguide to use CHECK: lines as
a common matching prefix at various places. Also note that

; CHECK, CHECK-V83A: ...

line only matches the "CHECK-V83A" prefix.

This commit explicitly splits the checks into common ones (CHECK) and
invocation-specific ones (COMPAT and V83A) and updates the assertions
with the update_llc_test_checks.py script.

Reviewed By: efriedma, MaskRay

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

(cherry picked from commit 4210204f)

Set the ReplaceFlags variable to false, since there is code meant only
for the ADDItocHi/ADDItocL nodes. This has the side effect of disabling
the peephole when the load/store instruction has a non-zero offset.
This patch also fixes retrieving the `ImmOpnd` node from the AIX small
code model pseduos and does the same for the register operand node.
This allows cleaning up the later calls to replaceOperands.
Finally move calculating the MaxOffset into the code guarded by
ReplaceFlags as it is only used there and the comment is specific to the ELF
ABI.

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

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

(cherry picked from commit b37c7ed0)

There are cases where the -1 doesn't become visible until lowering
so the folding doesn't have a chance to run.

I think in these cases there is a missed DAGCombine for truncate (undef),
which I may fix separately, but RISC-V backend should protect itself.

Fixes #64503.

Reviewed By: asb

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

(cherry picked from commit 7cc61541)

The llvm-rc tool tries to locate a suitable Clang executable to
use for preprocessing. For this purpose, it first checks within
the same directory as the llvm-rc tool, checking with a couple
different names, followed by checking all of $PATH for another
couple names.

On Windows, the InitLLVM() function always sets up Argv[0] with the
full path to the executable, while on Unix, Argv[0] is kept as is.

Therefore, call getMainExecutable to try to resolve the directory of
the executable before looking for colocated Clang executables.

This makes 282744a9 actually have
the desired effect.

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

(cherry picked from commit 8c6a0c8b)

As suggested by @ldionne.

Reviewed By: ldionne, #libc, avogelsgesang

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

(cherry picked from commit cf83cfb3)

It isn't mutated during the conversion already, communicate this through the API.

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

This method should not load new dialect or affect the context itself.

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

Previously, foldExtractFromBroadcast() would incorrectly fold:

  func.func @extract_from_stretch_broadcast(%src: vector<3x1x2xf32>) -> f32 {
    %0 = vector.broadcast %src : vector<3x1x2xf32> to vector<3x4x2xf32>
    %1 = vector.extract %0[0, 2, 0] : vector<3x4x2xf32>
    return %1: f32
  }

to:

  func.func @extract_from_stretch_broadcast(%src: vector<3x1x2xf32>) -> f32 {
    %0 = vector.extract %src[0, 2, 0] : vector<3x1x2xf32>
    return %0: f32
  }

This was due to the wrong offset being used when zeroing the "dim-1"
broadcasted dims. It should use the difference in rank across the
broadcast as the starting offset, as the ranks after that are the ones
that could have been stretched.

Reviewed By: awarzynski, dcaballe

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

This revision uses std::array instead of normal c arrays to store the
operand and result segment sizes. This is a follow up to
https://reviews.llvm.org/D155919, which converted the operand and result
segment sizes to properties. Its use of c arrays triggered warnings in
downstream projects due to the direct comparison of c arrays. This
revision fixes the warnings using std::arrays that implement a
proper comparison operator, which compares the array elements rather
that the array pointers.

Note: it seems the comparison operator is effectively dead code for now.
It still seems useful to fix the warning and ensure the comparison works
as expected assume someone starts using it at some point in time.

Reviewed By: mehdi_amini

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

Leaving this field unitialized could led to crashes when it'll diverge from the
IRNumbering phase.

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

When the operation has no attributes, the generated assertion is
always false and triggers lots of warnings in the build.

```
warning: comparison of unsigned expression < 0 is always false
```

Just return a StringAttr when there is no attribute.

Reviewed By: mehdi_amini

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

The `allocsize` attribute is weird because it packs two 32-bit values
into a 64-bit value. It also turns out that the passthrough attribute
exporter was using `int`, which is incorrectly handling 64-bit integers.

Reviewed By: rriddle

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