The only use was already guarded by a different lock in the caller of
loadBinary.

This pass is broken and looks like no one uses it for the last 15+ years.

```c++
bool Printer::runOnFunction(Function &F) {
  if (F.hasGC())
    return false;

  GCFunctionInfo *FD = &getAnalysis<GCModuleInfo>().getFunctionInfo(F);
```
```c++
GCFunctionInfo &GCModuleInfo::getFunctionInfo(const Function &F) {
  assert(!F.isDeclaration() && "Can only get GCFunctionInfo for a definition!");
  assert(F.hasGC()); // Equivalent to `assert(false);` when called by `Printer::runOnFunction`
```

See also #74972.

Refactor the percentage display in the secondary code. Re-use that to
display a utilization percentage when displaying fragmentation data.

lldb was rehashing the string 3 times (once to determine which StringMap
to use, once to query the StringMap, once to insert) on insertion (twice
on successful lookup).

This patch allows the lldb to benefit from hash improvements in LLVM
(from djbHash to xxh3).

Though further changes would be needed to cache this value to disk - we
shouldn't rely on the StringMap::hash remaining the same in the
future/this value should not be serialized to disk. If we want cache
this value StringMap should take a hashing template parameter to allow
for a fixed hash to be requested.

Useful for lldb's const string pool, using the hash to determine which
string map to lock and query/insert.

Derived from https://reviews.llvm.org/D122974 by Luboš Luňák

Use `tensor.empty` + initialization for dense tensors instead of
`bufferization.alloc_tensor`.

We were not setting size field of .debug_str_offsets correctly. Fixed
it, and added a test.

`Region::walk([](Block *b) {...})` does not enumerate blocks that are
direct children of the region. These blocks must be checked manually.

Similar to d20190e6

This fix was merged into 17.0.3 (commit 69c8c966), so the release
note for Clang 18 should be removed.

Change the lto-flags test case to check for `-bdbg:thinlto` on AIX

---------

Co-authored-by: Mark Danial <mark.danial@ibm.com>

https://reviews.llvm.org/D154014 addes glob support and enables it when
`#!special-case-list-v2` is the first line. This patch makes the glob
support the default (faster than regex after
https://reviews.llvm.org/D156046) and switches to the deprecated regex
support if `#!special-case-list-v1` is the first line.

I have surveyed many ignore lists. All ignore lists I find only use
basic `*` `.` and don't use regex metacharacters such as `(` and `)`.
(As neither `src:` nor `fun:` benefits from using regex.)
They are unaffected by the transition (with a caution that regex
`src:x/a.pb.*` matches `x/axpbx` but glob `src:x/a.pb.*` doesn't).

There is no deprecating warning. If a user finds
`#!special-case-list-v1`, they shall read that the old syntax is
deprecated.

Link:
https://discourse.llvm.org/t/use-glob-instead-of-regex-for-specialcaselists/71666

This will result in larger atomic operations getting expanded to
`__atomic_*` libcalls via AtomicExpandPass, which matches what Clang
already does in the frontend.

Additionally, adjust some comments, and remove partial code dealing with
larger-than-128bit atomics, as it's now unreachable.

AArch64 always supports 128-bit atomics, so there's no conditionals
needed here. (Though: we really ought to require that a 128-bit load is
available, not just a cmpxchg, which would mean conditioning on LSE2.
But that's future work.)

The arm64-irtranslator.ll test was adjusted as it was using an i258 type
as a hack to avoid IR atomic lowering to test GlobalISel behavior. Pass
-mattr=+lse and use i32, instead, to accomplish that goal in a way that
continues to work.

The newly introduced LocationListLookupTestCase.test_loclist_expr test
fails with older clangs.

SimpleMachOHeaderMU can be used as a convenient base for classes that create
custom MachO headers. Instances of these custom classes can be used by passing
a MachOHeaderMUBuilder using the MachOPlatform extensions added in ef314d39.

Support was added for the following fusions:
  auipc-addi, slli-srli, ld-add
Some parts of the code became repetative, so small refactoring of
existing lui-addi fusion was done.

Reverting a workaround intended specifically for SPRI-V. That workaround
emerged from this discussion:

  * https://github.com/llvm/llvm-project/pull/72105

AFAIK, it hasn't been required in practice. This is based on IREE
(https://github.com/openxla/iree), which has just bumped it's fork of
LLVM without using it (*).

(*) https://github.com/openxla/iree/commit/cef31e775e03ec83420e4a7b47a992242d8df37c

This reverts commit bbd2b08b.

Clang's support for atomic operations on long doubles is currently broken,
so these tests don't work everywhere. This is a long standing condition and
the goal of this patch is to get the CI green again on all platforms.

The actual Clang fixes will be pursued separately.

Fixes #73791

For a character literal that is split over more than one source line
with free form line continuation using '&'
at the end of one line but missing the standard-required '&' on the
continuation line, also handle the case of spaces at the beginning of
the continuation line.
    
For example,
    
PRINT *, 'don'&
   't poke the bear'
    
now prints "don't poke the bear", like nearly all other Fortran
compilers do.
    
This is not strictly standard conforming behavior, and the compiler
emits a portability warning with -pedantic.
    
Fixes llvm-test-suite/Fortran/gfortran/regression/continuation_1.f90,
.../continuation_12.f90, and .../continuation_13.f90.

There was some confusion about units (bytes vs characters) in the
handling of the amount of input remaining in fixed-width formatted input
fields. Clarify that any variable or parameter counting "remaining"
space in a field in the I/O runtime is always in units of bytes, and
make it so where it wasn't.

Fixes the bug(s) in
llvm-test-suite/Fortran/gfortran/regression/char4_iunit_2.f03, although
the test still won't pass due to its dependence on gfortran's
list-directed output spacing.

The overflow check didn't work for a 27-digit octal field containing an
80-bit x87 extended precision real value. The count of bytes required
was too large because the leading digit (1) was assumed to require a
full three bits. And the actual transmission of the octal input digits
to the output buffer was incorrect, too.

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

Most Fortran implementations support a READ statement after a WRITE
without repositioning on a sequential unit; it implies on ENDFILE and
then hits an EOF condition.

Fixes llvm-test-suite/Fortran/gfortran/regression/backspace_2.f.

This patch fixes:

  bolt/lib/Core/BinaryFunctionProfile.cpp:222:10: error: variable
  'BBMergeSI' set but not used [-Werror,-Wunused-but-set-variable]

  bolt/lib/Passes/VeneerElimination.cpp:67:12: error: variable
  'VeneerCallers' set but not used [-Werror,-Wunused-but-set-variable]

This makes it consistent with other builtins that require a specific
extension.

The "to be enabled" seemed unnecessary.

… input

The current EOF detection method (IsAtEOF()) depends on comparing the
current record number with the record number of the endfile record, if
it is known, which it is for units that have been written and then
rewound for input. For formatted input, this is wrong in the case of a
unit written with in-band newline characters. Rather than scan output
data to count newlines, it's best to just organically determine EOF by
detecting a failed or short read(), as we would have done anyway had the
endfile record number not been known. (I considered resetting the
endfile record number at the point of a REWIND, but not all rewinds are
followed by input; it seems wiser to defer the resetting until an actual
READ takes place.)

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

Lowering doesn't use it, and won't need it in the future; it emits
in-line code for conversions and for assignments to scalars, and uses
the general Assign() routine for arrays.

…was written

At the end of an internal output statement, The I/O runtime fills (the
remainder of) the current record with blanks if it's the only record or
if anything had been written to it. This turns out to be wrong in the
case of a format that ends with an explicit advance to the next record,
which needs to be cleared even if nothing has been written.

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