Linux kernel fs/binfmt_elf_fdpic.c supports FDPIC for MMU-less systems.
GCC/binutils/qemu support FDPIC ABI for ARM
(https://github.com/mickael-guene/fdpic_doc).
_ARM FDPIC Toolchain and ABI_ provides a summary.

This patch implements FDPIC relocations to the integrated assembler.
There are 6 static relocations and 2 dynamic relocations, with
R_ARM_FUNCDESC as both static and dynamic.

gas requires `--fdpic` to assemble data relocations like `.word
f(FUNCDESC)`.
This patch adds `MCTargetOptions::FDPIC` and reports an error if FDPIC
is not set.

Created using spr 1.3.4

[skip ci]

According to [expr.prim.id.qual] p3:
> The _nested-name-specifier_ `​::` nominates the global namespace. A
_nested-name-specifier_ with a _computed-type-specifier_ nominates the
type denoted by the _computed-type-specifier_, which shall be a class or
enumeration type. **If a _nested-name-specifier_ `N` is declarative and
has a _simple-template-id_ with a template argument list `A` that
involves a template parameter, let `T` be the template nominated by `N`
without `A`. `T` shall be a class template.**

Meaning, the out-of-line definition of `A::f` in the following example
is ill-formed:
```
template<typename T>
struct A 
{ 
    void f(); 
};

template<typename T>
using B = A<T>;

template<typename T>
void B<T>::f() { } // error: a declarative nested name specifier cannot name an alias template
```

This patch diagnoses such cases as an extension (in group `alias-template-in-declaration-name`).

The SectCreateMaterializationUnit creates a LinkGraph with a single named
section containing a single named block whose content is given by a
MemoryBuffer. It is intended to support emulation of ld64's -sectcreate option.

Summary:
This cleans up the handling of hermetic test flags. Primarily done to
simplify the GPU rework patch.

This reverts commit 3f0404aa.

std::reverse is breaking some builds

Patch  3f0404aa is breaking some debugs build so we cannot use the reverse here.

This reverts commit 493f1010.

[Clang][Sema] Convert warning for extraneous template parameter lists to an extension warning (#82277)

We currently accept the following explicit specialization with a warning
for the extraneous template parameter list:
```
template<typename T>
void f();

template<>
template<>
void f<int>(); // warning: extraneous template parameter list in template specialization
```

This should really be an extension warning so we reject with
`-pedantic-errors`. This patch converts the warning to an extension
warning.

[InstCombine] foldFCmpIntToFPConst - simplify repeated calls to getBitWidth/getScalarSizeInBits. NFC.

Noticed on #82241 - we don't need to use the IntegerType just for the scalar width, and we were calling it 3 times in different forms - we can just call Type::getScalarSizeInBits once and reuse.

This updates the signal handle thread coordinating to use a user signal
bit on the SignalHandlerEvent to coordinate shutdown instead of closing
the event handle. Closing the event handle is racy as the handle may be
closed before the signal handler thread resolves the handle value in
_zx_object_wait_many() and we would like to make this an explicit error.
Using the user signal bit 1 instead and then closing the event object
after the signal handler thread is joined cannot race as the wait will
terminate whether the signal is raised before or after the wait begins.

When MergeFunctions creates new thunk functions, it needs to copy over
the debug info format kind from the original function, otherwise we'll
mix debug info formats and run into assertions. This was exposed by a
downstream change that runs MergeFunctions before inlining, which caused
assertions when inlining attempted to inline thunks created by merging,
and the added test covers both scenarios where merging creates thunks.

This patch adds support for expected InstallAPI inputs. InstallAPI
accepts a well defined filelist of headers and how those headers
represent a single library.

InstallAPI captures header files to determine linkable symbols to then
compare against what was compiled in a binary dylib and generate TBD
files.

[lldb-dap] Do not write over the existing error if launchCommands fail during debugger launch. (#82051)

This fixes an issue where the error is lost if a command while executing
`launchCommands` when launching the debugger.

This should fix #82048

bot failure: https://lab.llvm.org/buildbot/#/builders/19/builds/24831

(#79887) When the offset of a PT_INTERP segment equals the offset of a
PT_LOAD segment, we consider that the parent of the PT_LOAD segment is
the PT_INTERP segment. In `layoutSegments`, we place both segments to be
after the current `Offset`, ignoring the PT_LOAD alignment.

This scenario is possible with fixed section addresses, but doesn't
happen with default linker layouts (.interp precedes other sections and
is part of a PT_LOAD segment containing the ELF header and program
headers).

```
% cat a.s
.globl _start; _start: ret
.rodata; .byte 0
.tdata; .balign 4096; .byte 0
% clang -fuse-ld=lld a.s -o a -nostdlib -no-pie -z separate-loadable-segments -Wl,-Ttext=0x201000,--section-start=.interp=0x202000,--section-start=.rodata=0x202020,-z,nognustack
% llvm-objcopy a a2
% llvm-readelf -l a2   # incorrect offset(PT_LOAD)
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000000000200040 0x0000000000200040 0x0001c0 0x0001c0 R   0x8
  INTERP         0x001001 0x0000000000202000 0x0000000000202000 0x00001c 0x00001c R   0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x000000 0x0000000000200000 0x0000000000200000 0x000200 0x000200 R   0x1000
  LOAD           0x001000 0x0000000000201000 0x0000000000201000 0x000001 0x000001 R E 0x1000
//// incorrect offset
  LOAD           0x001001 0x0000000000202000 0x0000000000202000 0x000021 0x000021 R   0x1000
  LOAD           0x002000 0x0000000000203000 0x0000000000203000 0x000001 0x001000 RW  0x1000
  TLS            0x002000 0x0000000000203000 0x0000000000203000 0x000001 0x000001 R   0x1000
  GNU_RELRO      0x002000 0x0000000000203000 0x0000000000203000 0x000001 0x001000 R   0x1000
```

The same issue occurs for PT_TLS/PT_GNU_RELRO if we PT_TLS's alignment
is smaller and we place the PT_LOAD after PT_TLS/PT_GNU_RELRO segments
(not linker default, but possible with a `PHDRS` linker script command).

Fix #79887: when two segments have the same offset, order the one with a
larger alignment first. In the previous case, the PT_LOAD segment will
go before the PT_INTERP segment. In case of equal alignments, it doesn't
matter which segment is treated as the parent segment.

When PSHUFB is used as a LUT (for CTPOP, BITREVERSE etc.), its the source operand that is constant and the index operand the variable. As long as the indices don't set the MSB (which zeros the output element), then the common known bits from the source operand can be used directly, even though the shuffle mask isn't constant.

Further helps to improve CTPOP reduction codegen

[OpenMP][AIX]Add assembly file containing microtasking routines and unnamed common block definitions (#81770)

This patch adds assembly file `z_AIX_asm.S` that contains the 32- and
64-bit XCOFF version of microtasking routines and unnamed common block
definitions. This code has been run through the libomp LIT tests and a
user package successfully.

C23 added the wb and uwb suffixes to generate a bit-precise integer
value. These values can be larger than what is representable in intmax_t
or uintmax_t.

We were asserting that an enumerator constant could not have a value
larger than unsigned long long but that's now a possibility. This patch
turns the assertion into a "value too large" diagnostic.

Note, we do not yet implement WG14 N3029 and so the behavior of this
patch will cause the enumerator to be cast to unsigned long long, but
this behavior may change in the future. GCC selects __uint128_t as the
underlying type for such an enumeration and we may want to match that
behavior in the future. This patch has several FIXME comments related to
this and the release notes call out the possibility of a change in
behavior in the future.

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

Unify VPlan verifiers in verifyVPlanIsValid. This adds verification for
various properties on blocks to the verifier used for VPlans generated
by the inner loop vectorizer. It also adds def-use checks for the
verifier used in the VPlan native path.

This drops the separate flag to enable HCFG verification. Instead, all
VPlans are verified once they have been created, if assertions are
enabled.

This also removes VPWidenPHIRecipe from VPHeaderPHIRecipe; it is used to
model any phi node in the native path.

Current we only support `C` as the remainder, but we can also limit
with a constant numerator.

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

Closes #82303

fix the issue that `__has_builtin` is undefined on some non-clang
targets.

See docs at
- https://gustedt.gitlabpages.inria.fr/c23-library/#stdckdint
- https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf (Ch7.10)

Compiler header:
-
https://github.com/llvm/llvm-project/blob/450462cbaceddf57812ce15b5135b17f65a77654/clang/lib/Headers/stdckdint.h
- New version of GCC
(https://github.com/gcc-mirror/gcc/blob/cd503b0616462445381a8232fb753239d319af76/gcc/ginclude/stdckdint.h)
also provides this.

It turns out there's a pathway for Functions to be inserted into modules
without having the "New" debug-info flag set correctly, which this patch
fixes. Sadly there isn't a Module::insert method to instrument out
there, everyone touches the list directly.

This fix exposes a path where such functions are produced in the
outliner in the wrong mode; requiring a fix there to correctly drop
RemoveDIs-mode debug-info. This is covered by
test/DebugInfo/AArch64/ir-outliner.ll

Patch 1 of 3 to add llvm.dbg.label support to the RemoveDIs project. The
patch stack adds a new base class

    -> 1. Add DbgRecord base class for DPValue and the not-yet-added
          DPLabel class.
       2. Add the DPLabel class.
       3. Enable dbg.label conversion and add support to passes.

Patches 1 and 2 are NFC.

In the near future we also will rename DPValue to DbgVariableRecord and
DPLabel to DbgLabelRecord, at which point we'll overhaul the function
names too. The name DPLabel keeps things consistent for now.

Add `atomic_signal_fence`. This will be useful in
https://gustedt.gitlabpages.inria.fr/c23-library/#memset_explicit.

If the vXi8 add(X,Y) is guaranteed not to overflow then we can push the addition though the psadbw nodes (being used for reduction) and only need a single psadbw node.

Noticed while working on CTPOP reduction codegen

[X86] combineEXTRACT_SUBVECTOR - share the same SDLoc argument instead of recreating it over and over again.

IV variable are privatized during acc loop lowering. An hlfir.declare
operation is added when mapping the symbol to the new private value. In
order to avoid using multiple value in the acc.loop region, we map the
symbol to the result of the hlfir.declare operation inserted.

Currently there are two versions of llvm::unique, one that requires a
predicate, and is in STLExtras.h; and one that does not require a
predicate, and is in GenericUniformityImpl.h. This moves the one from
GenericUniformityImp.h to STlExtras.h, so they are both together, and
can both be easily called from other places inside LLVM.

This patch adds some tests for
https://github.com/llvm/llvm-project/pull/82344.

This patch extends [D36234](https://reviews.llvm.org/D36234) to handle
`zext nneg` instructions.
I found this while adding support for cast instructions in
`getFreelyInvertedImpl`.

This patch removes the `-reverse-csr-restore-seq` option from
AArch64FrameLowering, since this is no longer used.

The section headers for XCOFF files have a subtype flag for Dwarf
sections. This PR updates obj2yaml, yaml2obj, and llvm-readobj so that
they recognize the subtype.

This unrolls n-D vector.interleave ops like:

```mlir
vector.interleave %i, %j : vector<6x3xf32>
```

To a sequence of 1-D operations:
```mlir
%i_0 = vector.extract %i[0] 
%j_0 = vector.extract %j[0] 
%res_0 = vector.interleave %i_0, %j_0 : vector<3xf32>
vector.insert %res_0, %result[0] :
// ... repeated x6
```

The 1-D operations can then be directly lowered to LLVM.

Depends on: #80966

This adds predefined formatting macros in C23 mode for printing unsigned
integers in binary format (e.g, UINT_FAST64_FMTB). These are used to
implement the PRIb (et al) macros in inttypes.h

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

(Was previously reviewed in
[82037](https://github.com/llvm/llvm-project/pull/82037), this is fixing
some failures found post-commit.)

widenIVUse may hoist a wide induction increment and introduce new uses,
but does not recompute the wrap flags. In some cases this can make the
new uses of the wide IV inc more poisonous.

Update the code to recompute flags if needed when hoisting an IV. If
both the narrow and wide IV increment's flags match and we can re-use
the flags from the increments, there's no need to recompute the flags,
as the replacement won't make the new uses of the wide IV's increment
more poisonous.

Note that this also updates a stale comment which claimed that the widen
increment is only used if it dominates the new use.

The helper should also be used to guard the code added in da437330,
which I am planning on doing separately once the helper lands.

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