Summary:
This patch cleans up some of the JIT handling for AMDGPU as well as
removing its temporary files. Previously these would be left in the
temporary directory after the program was run. This costs some extra
time, but the correct solution to avoid that is to create a sufficient
entrypoint into `ld.lld` that we can simply pass a memory buffer into.

[Clang] Only compare template params of potential overload after checking their decl context (#78139)

Fixes a regression from 69066ab3 in which we compared the template lists
of potential overloads before checkings their declaration contexts.

This would cause a crash when doing constraint substitution as part of
that template check, because we would try to refer to not yet
instantiated entities (the underlying cause is unclear).

This patch reorders (again) when we look at template parameter so we
don't do it when checkings friends in different lexical contexts.

Fixes #77953
Fixes #78101

llvm-project/mlir/lib/Dialect/Mesh/IR/MeshOps.cpp:204:25:
 error: comparison of integers of different signs: 'size_t' (aka 'unsigned long') and 'int64_t' (aka 'long') [-Werror,-Wsign-compare]
  if (getShape().size() > rank)
      ~~~~~~~~~~~~~~~~~ ^ ~~~~
1 error generated.

This patch adds an optional offloading handler attribute to
the`gpu.module` op. This attribute will be used during
`gpu-module-to-binary` pass to override the offloading handler used in
the `gpu.binary` op.

The `_POSIX_SOURCE` macro is defined without a value on AIX. Change the check to `defined(_POSIX_SOURCE)`. 

Extra test for https://github.com/llvm/llvm-project/pull/77827, where
NUW gets added the AddRec due to the BTC being 0.

[llvm][frontend][offloading] Move clang-linker-wrapper/OffloadWrapper.* to llvm/Frontend/Offloading (#78057)

This patch moves `clang/tools/clang-linker-wrapper/OffloadWrapper.*` to
`llvm/Frontend/Offloading` allowing them to be re-utilized by other
projects.

Additionally, it makes minor modifications to the API to make it more
flexible.
Concretely:
 - The `wrap*` methods now have additional arguments `EntryArray`, 
`Suffix` and `EmitSurfacesAndTextures` to specify some additional options.
- The `EntryArray` is now constructed by the caller. This change is needed to
enable JIT compilation, as ORC doesn't fully support `__start_` and `__stop_` 
symbols. Thus, to JIT the code, the `EntryArray` has to be constructed explicitly in the IR.
- The `Suffix` field is used when emitting the descriptor, registration
methods, etc, to make them more readable. It is empty by default.
- The `EmitSurfacesAndTextures` field controls whether to emit surface
and texture registration code, as those functions were removed from `CUDART`
in CUDA 12. It is true by default.
- The function `getOffloadingEntryInitializer` was added to help create
the `EntryArray`, as it returns the constant initializer and not a global
variable.

Add a paragraph to Extensions.md that fell out of a recent patch.

We only ever call this function once, without relying on the defaulted
`honor_array` parameter, so make it non-defaulted. Also `max_length` is
always set to `0`, so remove it entirely.

This simplifies some upcoming refactoring.

[flang] Catch more initialization errors
    
    Diagnose some error cases related to initialization that are
slipping past semantic checking: don't allow multiple initializations
    of the same symbol, and don't allow an object that was initialized
    as a scalar to become an array afterward.
    
Fixes llvm-test-suite/Fortran/gfortran/regression/initialization_17.f90.

The main reason for adding the toolchain paths early was to prefer
libraries from the toolchain over ones from MSVC (primarily for
compiler-rt builtins). But if the user specifies a directory explicitly
with the -libpath: option, that should be preferred over the built-in
default paths.

This fixes an issue raised at
https://discourse.llvm.org/t/lld-prefers-system-llvm-libraries-to-user-provided-ones-on-windows/76148.

…character

Don't omit the leading space in list-directed output before a line
comprising only a zero-length character value.

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

In
    CALL FOO
    PRINT *, ABS(FOO)
we currently resolve the first FOO to a global external subprogram, but
then the second FOO is treated as an implicitly typed local variable.
This happens because the name FOO is not present in the local scope.

Fix by adding FOO to the local scope using a place-holding
HostAssocDetails symbol whose existence prevents the creation of another
FOO in the local scope. The symbol stored in the parser::Name parse tree
nodes or used in typed expressions will all continue to point to the
global external subprogram.

Resolves llvm-test-suite/Fortran/gfortran/regression/pr71859.f90.

Using the VALUE attribute for assumed-length CHARACTER dummy arguments
became standard in F'2008 but still lacks widespread implementation;
emit a portability warning when they are enabled.

Resolves llvm-test-suite/Fortran/gfortran/regression/value_5.f90.

Closes #75620 

As I mentioned on the issue, this PR aims to hash-pin the CI
dependencies used on sensitive context -- i.e., they either are called
with write permissions, or are being used to build critical artifacts
like a release. In summary, this PR brings 3 changes:

1. Hash pin GitHub Actions called on sensitive context
2. Hash pin python dependencies used on sensitive context
3. Configure dependabot to automatically update those hashes
I'm further explaining the steps bellow.

The dependencies in format of GitHub Actions, I simply hash-pinned them.
I also made sure to keep the human-readable version as comments at the
same line.

At the
[release-tasks.yml](https://github.com/llvm/llvm-project/blob/main/.github/workflows/release-tasks.yml)
file, I've changed the installation method of some python dependencies
to install them considering their hashpinning. That required the
generation of a requirements file that had all the correct hashes, and
for that I used [pip-tools](https://pypi.org/project/pip-tools/2.0.0/).

While configuring dependabot, I set it to send a monthly PR updating all
the GitHub Actions, and a weekly PR to update any python dependency
required by
[/llvm/docs/requirements.txt](https://github.com/llvm/llvm-project/blob/main/llvm/docs/requirements.txt

).

Let me know if you have any questions or concerns, I'd be happy to
clarify and help.

Thanks!

---------

Signed-off-by: Diogo Teles Sant'Anna <diogoteles@google.com>

When an already-allocated allocatable array is about to fail
reallocation, don't allow its size or other characteristics to be
changed.

Fixes
llvm-test-suite/Fortran/gfortran/regression/multiple_allocation_1.f90
and .../multiple_allocation_3.f90.

Recognize Cray pointees as such when they are declared as assumed size
arrays, and don't emit a bogus error message about implied shape arrays.

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

`(ctpop (not x))` <-> `(sub nuw nsw BitWidth(x), (ctpop x))`. The
`sub` expression can sometimes be constant folded depending on the use
case of `(ctpop (not x))`.

This patch adds fold for the following cases:

`(add/sub/disjoint_or C, (ctpop (not x))`
    -> `(add/sub/disjoint_or C', (ctpop x))`
`(cmp pred C, (ctpop (not x))`
    -> `(cmp swapped_pred C', (ctpop x))`

Where `C'` depends on how we constant fold `C` with `BitWidth(x)` for
the given opcode.

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

Closes #77859

The checking of calls to the intrinsic subroutine MOVE_ALLOC is not
insisting that its first two arguments be whole allocatable variables or
components. Fix, move the code into check-calls.cpp (a better home for
such things), and clean up the tests.

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

The Fortran standard defines real MOD and MODULO with expressions like
MOD(a,p) = a - AINT(a/p)*p. Unfortunately, these definitions have poor
accuracy when a is much larger in magnitude than p, and every Fortran
compiler uses better algorithms instead.

Fixes llvm-test-suite/Fortran/gfortran/regression/mod_large_1.f90.

Procedure interfaces emitted to module files are including IMPORT
statements for some symbols that don't need to be imported (base types
and procedure interfaces for components of imported derived types) and
omitting others (procedure interfaces for bindings in locally-defined
derived types that are material to the interface).

There are some very odd (even for Fortran) rules in F'2023 subclause
19.4 (paras 6 & 8) pertaining to the index variables of FORALL and DO
CONCURRENT constructs/statements, and they are not currently implemented
correctly.

Although these index variables are construct entities, they have
restrictions in the standard that would essentially allow them to also
be variables in their enclosing scopes. If their names are present in
the enclosing scope, and the construct does not have an explicit type
specification for its indices, then the names in the enclosing scope
must either be scalar variables or COMMON blocks, and their type must be
integer.

Reimplement these restrictions largely with portability warnings rather
than hard errors. Retain the semantic interpretation that the type of an
untyped index variable be taken from the type of a variable of the same
name in the enclosing scope, if it exists, although that bit of the
standard could be interpreted otherwise.

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

Removes logic that caused some fixups to be marked as resolved in the
assembler without actually resolving them. Assembler must either resolve
the fixup, reject the code (error out) or defer the resolution to the
linker. In general assembler can resolve offsets in pcrel instructions
if the symbol referred to is in the same section and it cannot make
assumptions about relative position of sections. For example, when LDRD
instruction in arm mode is encountered, fixup_arm_pcrel_10_unscaled is
raised. Prior to https://github.com/llvm/llvm-project/pull/72873/ the
assembler would always mark it as resolved without generating a
relocation. The resulting code would likely be incorrect whenever the
label referred to is in a different section.

This patch finishes the series to prevent incorrect code being generated
for pcrel instructions referring to labels in different sections. This
kind of assembly code is very rare and most likely a user error, so both
options (relocation or error) are acceptable. In previous patches this
was resolved by adding relocations. Here, for VLDR instructions an error
is generated as relocation does not exist for Thumb mode and we wanted
the tool's behaviour to be consistent across modes. In the LDRD case,
Thumb mode does not have a relocation and errors out, but LDRD in Arm
mode generates R_ARM_LDRS_PC_G0 relocation because its fixup kind is
shared with other instructions.

It also fixed the case when ADR is used in the big-endian mode, which is
not covered by the ADR patch.

Patch series:
https://github.com/llvm/llvm-project/pull/72873 - LDRx
https://github.com/llvm/llvm-project/pull/73834 - ADR 
this PR - LDRD and VLDR

This reverts commit cab156c4, and adds
language to Extensions.md documenting the discrepancy with the letter of
the language standard.

The usage of FP Load and Test instructions as a comparison against zero
with the assumption that the dest reg will always reflect the source reg is
actually incorrect: Unfortunately, a SNaN will be converted to a QNaN, so the
instruction may actually change the value as opposed to being a pure register
move with a test.

This patch
- changes instruction selection to always emit FP LT with a scratch def
  reg, which will typically be allocated to the same reg if dead.
- Removes the conversions into FP LT in SystemZElimcompare.

Detect NaN elements in data and handle them like gfortran does (at
runtime); namely, NaN can be returned if all the data are NaNs, but any
non-NaN value is preferable. Ensure that folding returns the same
results as runtime computation.

Fixes llvm-test-suite/Fortran/gfortran/regression/maxloc_2.f90 (and
probably others).

GFX12 can still encode the s_set_inst_prefetch_distance instruction but
it has no effect.

The implementation of MAXLOC/MINLOC without DIM=1 is wrong for CHARACTER
data -- change it to use the character comparator rather than the
numeric comparator.

Fixes llvm-test-suite/Fortran/gfortran/regression/maxloc_string_1.f90.

strsep, strtok_r, strlcpy, and strlcat take restricted pointers as
parameters.
Add the restrict qualifiers to them.

Sources:
https://man7.org/linux/man-pages/man3/strsep.3.html
https://man7.org/linux/man-pages/man3/strtok_r.3.html
https://man.freebsd.org/cgi/man.cgi?strlcpy

As NAMELIST output is a variant of list-directed output, its editing
must produce leading spaces on (most) output records to effect carriage
control. These spaces are required by the language standard and
implemented by nearly all other Fortran compilers (except GNU).

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