This commit makes two variables static.
That makes two buildbot tests pass with short string annotations.
I suspect that there may be use after end of life bug and it's fixed by
this change, but it requires confirmation.

Short string annotations PR (reverted):
- https://github.com/llvm/llvm-project/pull/79049

Tests fixed with this PR:
```
  LLVM :: Transforms/Inline/cgscc-inline-replay.ll 
  LLVM :: Transforms/SampleProfile/inline-replay.ll
```
Buildbot output:
https://lab.llvm.org/buildbot/#/builders/5/builds/40364/steps/9/logs/stdio

This PR does not resolve a problem with `Clang :: SemaCXX/builtins.cpp`,
related PR is:
- https://github.com/llvm/llvm-project/pull/79522

The epoll_wait functions are syscall wrappers that were requested by
upstream users. This patch adds them, as well as their header and types.

The tests are currently incomplete since they require epoll_create to
properly test epoll_wait. That will be added in a followup patch since
this one is already very large.

The code that parses repeat counts, field widths, &c. from FORMAT
strings has an incorrect overflow check, so the maximum integer value is
not accepted. Fix.

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

…edures

Fortran allows a generic interface to have the same name as a derived
type in the same scope. It also allows a generic interface to have the
same name as one of its specific procedures.

When two modules define the same name, possibly more than once each,
things get exciting. The standard is not clear, and other compilers do
variously different things. We are currently emitting some errors
prematurely for some usage in pfUnit due to how it combines two versions
of a package together via USE association.

This patch handles combinations of derived types and generic interfaces
and their specific procedures in a more principled way. Errors due to
ambiguity are deferred to actual usage of derived types and specific
procedures -- and when they're not used, the program is unambiguous and
no error issues.

…ystems

flang/test/Preprocessing/pp133.F90 -> pp134.F90 to avoid pp133.f90.

These specific intrinsic functions are legacy names that map to the
standard generic NINT(..., KIND=8).

On macOS, the formatter is printing signed values as
unsigned, it seems, and the tests are expecting correctly
signed values.  These tests were added in
https://github.com/llvm/llvm-project/pull/78609

The runtime implements CONVERT="SWAP", but semantics doesn't like it.
Add it to the relevant table.

Fixes llvm-test-suite/Fortran/gfortran/regression/record_marker_1.f90,
.../unf_io_convert_1.f90, .../unf_io_convert_2.f90, and
.../unf_io_convert_3.f90.

We support specific intrinsic calls like `AMAX0(1.0,2)` that have
heterogeneous argument types as an optional extension in cases where the
specific intrinsic has a related generic intrinsic function capable of
handling the argument types. This feature can't be allowed to apply to
calls where the result of the related generic intrinsic function is not
convertible to the type of the specific intrinsic, as in `AMAX0('a',
'b')`.

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

CheckIPOSupported is used to test for working LTO since #74520. However, before CMake 3.24 this will test the default linker and ignore options such as LLVM_ENABLE_LLD. As a result, CMake would test whether LTO works with the default linker but builds with another one. In a typical scenario, libomptarget is compiled with the in-tree Clang, but linked with ld.gold, which requires the LLVMgold plugin, when it actually would work with the lld linker (or also fail because the system lld is too old to understand opaque pointers). Using gcc as the compiler would pass the test, but fail when linking with lld since does not understand gcc's LTO format.

Disable LTO by default for now since automatic detection causes too many problems. It causes the openmp-offload-cuda-project buildbot (https://lab.llvm.org/staging/#/builders/151) to fail and LLVM_ENABLE_RUNTIMES=openmp builds will have it implicitly disabled in the vast majority of system configurations anyway.

https://github.com/llvm/llvm-project/issues/78927 contains a case of
fixed-form source in which a Hollerith literal is mistakenly tokenized,
leading to grief later due to apparently unbalanced parentheses.

The source looks like "REAL*8 R8HEAP(SCRSIZE)" and the Hollerith literal
is misrecognized as such because it follows "8R". In order to properly
tokenize Hollerith literals in old comma-free FORMAT statements like "1
FORMAT(3I5HFLANG)", the tokenizer in the prescanner treats a letter
after an integer token ("3I") as a special case. The fix is to do this
only when the characters involved are nested in parentheses and
Hollerith is a possibility.

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

Some Fortran codes use line continuation as a form of token pasting; see
https://github.com/llvm/llvm-project/issues/78797. This works in
compilers that run a C-like preprocessor and then apply line
continuation to its output; f18 implements line continuation during
tokenization and preprocessing, but can still handle this case.

In the rare case when an identifier is split across two or more
continuation lines, this patch allows its parts to be distinct
preprocessing tokens for the purpose of macro replacemnt. They (or their
replacement texts) can be effectively rejoined later as a single
identifier when the cooked character stream is tokenized in parsing.

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

The utility function GetRelevantObject() seems to be just wrong for
definability checks for the "base object" of a designator, and that's
all for which it is (now?) used. This leads to some false error messages
in Whizard when data-refs with multiple pointer components are defined.
Simplify, and add more test cases.

Encode BRANCHENTRY bits as bitmask for deduplicated entries.

Reduces BAT section size:
- large binary: to 11834216 bytes (0.31x original),
- medium binary: to 1565584 bytes (0.26x original),
- small binary: to 336 bytes (0.23x original).

Test Plan: Updated bolt/test/X86/bolt-address-translation.test

When an attribute specification statement follows a declaration that
applies the SAVE attribute to a symbol, name resolution can produce a
spurious error message about redundant SAVEs.

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

In instcombine, when we sink an instruction into a successor block, we try
to clone and salvage all the variable assignments that use that Value. This
is a behaviour that's (IMO) flawed, but there are important use cases where
we want to avoid regressions, thus we're implementing this for the
non-instruction debug-info representation.

This patch refactors the dbg.value sinking code into it's own function, and
installs a parallel implementation for DPValues, the non-instruction
debug-info container. This is mostly identical to the dbg.value
implementation, except that we don't have an easy-to-access ordering
between DPValues, and have to jump through extra hoops to establish one in
the (rare) cases where that ordering is required.

The test added represents a common use-case in LLVM where these behaviours
are important: a loop has been completely optimised away, leaving several
dbg.values in a row referring to an instruction that's going to sink. The
dbg.values should sink in both dbg.value and RemoveDIs mode, and
additionally only the last assignment should sink.

The new accurate algorithm for real MOD and MODULO in the runtime is not
as fast as std::fmod(), which is also accurate. So use std::fmod() for
those floating-point types that it supports.

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

An || operator in namelist substring bounds checking really needs to be
an && operator so that the substring is viewed as correct only when both
its bounds are valid.

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

Cray pointees may not appear in COMMON blocks or EQUIVALENCE groups.

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

Added an --comp-dir-override option that overrides DW_AT_comp_dir in the
unit die. This allows for llvm-bolt to be invoked from any category and
still find .dwo files.

Fortran allows the name of a generic interface to be the same as the
name of a derived type or specific procedure. When this happens, it
causes the code in module file generation to miss the symbol of a
derived type when scanning for symbols in initialization expressions
that need to be imported. Fix.

The standard requires a compiler to diagnose an incorrect use of a
pointer in a DEALLOCATE statement. The pointer must be associated with
an entire object that was allocated as a pointer (not allocatable) by an
ALLOCATE statement.

Implement by appending a validation footer to pointer allocations. This
is an extra allocated word that encodes the base address of the
allocation. If it is not found after the data payload when the pointer
is deallocated, signal an error. There is a chance of a false positive
result, but that should be vanishingly unlikely.

This change requires all pointer allocations (not allocatables) to take
place in the runtime in PointerAllocate(), which might be slower in
cases that could otherwise be handled with a native memory allocation
operation. I believe that memory allocation of pointers is less common
than with allocatables, which are not affected. If this turns out to
become a performance problem, we can inline the creation and
initialization of the footer word.

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

An Ew.0(Ee) or Ew.0(Ee) output edit descriptor with a scale factor of
zero is an error condition, unless the output edit descriptor was
originally Gw.0(Ee), list-directed, or just E0/D0 with no .d part.

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

The argument to the PRESENT() intrinsic function must be the name of a a
whole OPTIONAL dummy argument.

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

It's beneficial to have uniform reporting in both `infer-stale-profile`
on and off cases, primarily for logging purposes.

Without this change, BOLT would report "input" staleness in
`infer-stale-profile=0` case (without matching), and "output" staleness
in `infer-stale-profile=1` case (after matching).

This change makes BOLT report "input" staleness in both cases. "Output"
staleness information is printed separately with "BOLT-INFO: inferred
profile..."

The general implementation of intrinsic assignment of derived types in
the runtime support library has a doubly-nested loop: an outer loop that
traverses the components and inner loops than traverse the array
elements. It's done this way to amortize the per-component overhead.
However, this turns out to be wrong when the program cares about the
order in which defined assignment subroutines are called; the Fortran
standard allows less latitude here than we need to invert the ordering
in this way when any component is itself an array. So invert the two
loops: traverse the array elements, and for each element, traverse its
components.

Add support for device_type information on the acc.update operation and
update lowering from Flang.

Summary:
We support `--target=nvptx64-nvidia-cuda` as a way to target the NVPTX
architecture from standard CPU. This patch simply uses the existing
support for handling `--offload-arch=native` to also apply to the
standalone toolchain.

There's a few restrictions in the standard on the Fortran pointer
argument (FPTR=) to the intrinsic subroutine C_F_POINTER() that almost
no compilers enforce. Enforce them here with warnings.

Otherwise, when the base branch is not something that the CI runner
has checked out, that reference to e.g. release/18.x is ambiguous.

Support
R_RISCV_TLSDESC_HI20/R_RISCV_TLSDESC_LOAD_LO12/R_RISCV_TLSDESC_ADD_LO12/R_RISCV_TLSDESC_CALL.
LOAD_LO12/ADD_LO12/CALL relocations reference a label at the HI20
location, which requires special handling. We save the value of HI20 to
be reused. Two interleaved TLSDESC code sequences, which compilers do
not generate, are unsupported.

For -no-pie/-pie links, TLSDESC to initial-exec or local-exec
optimizations are eligible. Implement the relevant hooks
(R_RELAX_TLS_GD_TO_LE, R_RELAX_TLS_GD_TO_IE): the first two instructions
are converted to NOP while the latter two are converted to a GOT load or
a lui+addi.

The first two instructions, which would be converted to NOP, are removed
instead in the presence of relaxation. Relaxation is eligible as long as
the R_RISCV_TLSDESC_HI20 relocation has a pairing R_RISCV_RELAX,
regardless of whether the following instructions have a R_RISCV_RELAX.
In addition, for the TLSDESC to LE optimization (`lui a0,<hi20>; addi a0,a0,<lo12>`),
`lui` can be removed (i.e. use the short form) if hi20 is 0.

```
// TLSDESC to LE/IE optimization
.Ltlsdesc_hi2:
  auipc a4, %tlsdesc_hi(c)                      # if relax: remove; otherwise, NOP
  load  a5, %tlsdesc_load_lo(.Ltlsdesc_hi2)(a4) # if relax: remove; otherwise, NOP
  addi  a0, a4, %tlsdesc_add_lo(.Ltlsdesc_hi2)  # if LE && !hi20 {if relax: remove; otherwise, NOP}
  jalr  t0, 0(a5), %tlsdesc_call(.Ltlsdesc_hi2)
  add   a0, a0, tp
```

The implementation carefully ensures that an instruction unrelated to
the current TLSDESC code sequence, if immediately follows a removable
instruction (HI20 or LOAD_LO12 OR (LE-specific) ADD_LO12), is not
converted to NOP.

* `riscv64-tlsdesc.s` is inspired by `i386-tlsdesc-gd.s` (https://reviews.llvm.org/D112582).
* `riscv64-tlsdesc-relax.s` tests linker relaxation.
* `riscv-tlsdesc-gd-mixed.s` is inspired by `x86-64-tlsdesc-gd-mixed.s` (https://reviews.llvm.org/D116900).

Link: https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/373

Reviewed By: ilovepi

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

Move logic to replace congruent IV increments to helper function, to
reduce the indentation by using early returns. This is in preparation
for a follow-up patch.

We should diff against the base branch, not always against `main`. This
allows the BuildKite pre-commit CI to work properly when we target other
branches, such as `release/18.x`.

We used to support a /branch comment to specify a branch with commits to
backport to the release branch. However, now that we can use pull
requests this is not needed.

This also simplifies the process, because now the cherry-pick job can
create the pull request directly instead of having it split across two
separate jobs.

attempts, NFC.

If several iterations of reodering of orders is required, need to use
different algorithm.

[llvm-objdump,SHT_LLVM_BB_ADDR_MAP,NFC] Use auto && instead of const auto & to allow moving from BBAddrMap objects. (#79456)

std::move on `const auto &` references is essentially a noop. Changing
to `auto &&` to actually allow moving.

We recently noticed that the unwrap_iter.h file was pushing macros, but
it was pushing them again instead of popping them at the end of the
file. This led to libc++ basically swallowing any custom definition of
these macros in user code:

    #define min HELLO
    #include <algorithm>
    // min is not HELLO anymore, it's not defined

While investigating this issue, I noticed that our push/pop pragmas were
actually entirely wrong too. Indeed, instead of pushing macros like
`move`, we'd push `move(int, int)` in the pragma, which is not a valid
macro name. As a result, we would not actually push macros like `move`
-- instead we'd simply undefine them. This led to the following code not
working:

    #define move HELLO
    #include <algorithm>
    // move is not HELLO anymore

Fixing the pragma push/pop incantations led to a cascade of issues
because we use identifiers like `move` in a large number of places, and
all of these headers would now need to do the push/pop dance.

This patch fixes all these issues. First, it adds a check that we don't
swallow important names like min, max, move or refresh as explained
above. This is done by augmenting the existing
system_reserved_names.gen.py test to also check that the macros are what
we expect after including each header.

Second, it fixes the push/pop pragmas to work properly and adds missing
pragmas to all the files I could detect a failure in via the newly added
test.

rdar://121365472

[libc++] Update XFAIL for layout_stride/assert.conversion.pass.cpp in debug mode on PowerPC (#79169)

Adding the debug hardening modes into PowerPC target to check the
assertion messages, to fix the PPC rehl bot [1]. This is needed as 
58780b81 changed the assertion to trap in production hardening modes.

Properly fixing these assertions is tracked by #79216.

[1]: https://lab.llvm.org/buildbot/#/builders/57/builds/32354



Co-authored-by: Maryam Moghadas <maryammo@ca.ibm.com>