[Github] Add repository checks to release-binaries workflow (#84437)

This patch adds repository checks to the release-binaries workflow jobs.
People were observing that the job was running on a schedule in their
forks. This only happens on old forks, but those probably exist in great
number given how prolific LLVM is. This is also good practice anyways,
on top of solving the direct problem of these jobs running with the cron
schedule on people's forks.

(cherry picked from commit 9f5be5f0092a636274953389cd5771c45ac0a568)

[CMake][Release] Enable CMAKE_POSITION_INDEPENDENT_CODE (#90139)

Set this in the cache file directly instead of via the test-release.sh
script so that the release builds can be reproduced with just the cache
file.

(cherry picked from commit 53ff002c6f7ec64a75ab0990b1314cc6b4bb67cf)

[CMake][Release] Refactor cache file and use two stages for non-PGO builds (#89812)

Completely refactor the cache file to simplify it and remove unnecessary
variables. The main functional change here is that the non-PGO builds
now use two stages, so `ninja -C build stage2-package` can be used with
both PGO and non-PGO builds.

(cherry picked from commit 6473fbf2d68c8486d168f29afc35d3e8a6fabe69)

[CMake][Release] Add stage2-package target (#89517)

This target will be used to generate the release binary package for
uploading to GitHub.

(cherry picked from commit a38f201f1ec70c2b1f3cf46e7f291c53bb16753e)

Bump version to 18.1.6 (#91094)

[clang codegen] Fix MS ABI detection of user-provided constructors. (#90151)

In the context of determining whether a class counts as an "aggregate",
a constructor template counts as a user-provided constructor.

Fixes #86384

(cherry picked from commit 3ab4ae9e58c09dfd8203547ba8916f3458a0a481)

[RISCV][ISel] Fix types in `tryFoldSelectIntoOp` (#90659)

```
SelectionDAG has 17 nodes:
  t0: ch,glue = EntryToken
    t6: i64,ch = CopyFromReg t0, Register:i64 %2
  t8: i1 = truncate t6
          t4: i64,ch = CopyFromReg t0, Register:i64 %1
        t7: i1 = truncate t4
            t2: i64,ch = CopyFromReg t0, Register:i64 %0
          t10: i64,i1 = saddo t2, Constant:i64<1>
        t11: i1 = or t8, t10:1
      t12: i1 = select t7, t8, t11
    t13: i64 = any_extend t12
  t15: ch,glue = CopyToReg t0, Register:i64 $x10, t13
  t16: ch = RISCVISD::RET_GLUE t15, Register:i64 $x10, t15:1
```

`OtherOpVT` should be i1, but `OtherOp->getValueType(0)` returns `i64`,
which ignores `ResNo` in `SDValue`.

Fix https://github.com/llvm/llvm-project/issues/90652.

(cherry picked from commit 2647bd73696ae987addd0e74774a44108accb1e6)

[GlobalISel] Fix store merging incorrectly classifying an unknown index expr as 0. (#90375)

During analysis, we incorrectly leave the offset part of an address info
struct
as zero, when in actual fact we failed to decompose it into base +
offset.
This results in incorrectly assuming that the address is adjacent to
another store
addr. To fix this we wrap the offset in an optional<> so we can
distinguish between
real zero and unknown.

Fixes issue #90242

(cherry picked from commit 19f4d68252b70c81ebb1686a5a31069eda5373de)

[X86] Enable EVEX512 when host CPU has AVX512 (#90479)

This is used when -march=native run on an unknown CPU to old version of
LLVM.

(cherry picked from commit b3291793f11924a3b62601aabebebdcfbb12a9a1)

[GlobalISel] Don't form anyextending atomic loads.

Until we can reliably check the legality and improve our selection of these,
don't form them at all.

(cherry picked from commit 60fc4ac67a613e4e36cef019fb2d13d70a06cfe8)

[AArch64] Remove invalid uabdl patterns. (#89272)

These were added in https://reviews.llvm.org/D14208, which look like
they attempt to detect abs from xor+add+ashr. They do not appear to be
detecting the correct value for the src input though, which I think is
intended to be the sub(zext, zext) part of the pattern. We have pattens
from abs now, so the old invalid patterns can be removed.

Fixes #88784

(cherry picked from commit 851462fcaa7f6e3301865de84f98be7e872e64b6)

[clang][CoverageMapping] do not emit a gap region when either end doesn't have valid source locations (#89564)

Fixes #86998

(cherry picked from commit c1b6cca1214e7a9c14a30b81585dd8b81baeaa77)

[X86][EVEX512] Check hasEVEX512 for canExtendTo512DQ (#90390)

Fixes #90356

(cherry picked from commit 35b89dda2b9734917824b1457f149192669b314c)

 [CGP] Drop poison-generating flags after hoisting (#90382)

See the following case:
```
define i8 @src1(i8 %x) {
entry:
  %cmp = icmp eq i8 %x, -1
  br i1 %cmp, label %exit, label %if.then

if.then:
  %inc = add nuw nsw i8 %x, 1
  br label %exit

exit:
  %retval = phi i8 [ %inc, %if.then ], [ -1, %entry ]
  ret i8 %retval
}

define i8 @tgt1(i8 %x) {
entry:
  %inc = add nuw nsw i8 %x, 1
  %0 = icmp eq i8 %inc, 0
  br i1 %0, label %exit, label %if.then

if.then:                                          ; preds = %entry
  br label %exit

exit:                                             ; preds = %if.then, %entry
  %retval = phi i8 [ %inc, %if.then ], [ -1, %entry ]
  ret i8 %retval
}
```
`optimizeBranch` converts `icmp eq X, -1` into cmp to zero on RISC-V and
hoists the add into the entry block. Poison-generating flags should be
dropped as they don't still hold.

Proof: https://alive2.llvm.org/ce/z/sP7mvK
Fixes https://github.com/llvm/llvm-project/issues/90380

(cherry picked from commit ab12bba0aad800c1805eca2ea937da958c1854c8)

[Clang] Handle structs with inner structs and no fields (#89126)

A struct that declares an inner struct, but no fields, won't have a
field count. So getting the offset of the inner struct fails. This
happens in both C and C++:

  struct foo {
    struct bar {
      int Quantizermatrix[];
    };
  };

Here 'struct foo' has no fields.

Closes: https://github.com/llvm/llvm-project/issues/88931

[IRCE] Skip icmp ptr in `InductiveRangeCheck::parseRangeCheckICmp` (#89967)

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

(cherry picked from commit 22da5a6e34ed6146752b24d9156a678b50fddaef)

Fix Objective-C++ Sret of non-trivial data types on Windows ARM64 (#88671)

Linked to https://github.com/gnustep/libobjc2/pull/289.

More information can be found in issue: #88273.

My solution involves creating a new message-send function for this
calling convention when targeting MSVC. Additional information is
available in the libobjc2 pull request.

I am unsure whether we should check for a runtime version where
objc_msgSend_stret2_np is guaranteed to be present or leave it as is,
considering it remains a critical bug. What are your thoughts about this
@davidchisnall?

(cherry picked from commit 3dcd2cca7777b338d87deb1ca506df1376123667)

[clang-format] Fix a regression in ContinuationIndenter (#88414)

Commit d06b92391513 caused a regression that breaks after a block
comment adjacent to a function paramter that follows.

Fixes #86573.

(cherry picked from commit d61edecbfd099143e0e2617505fec921524938f8)

[clang-format] Fix a regression in annotating TrailingReturnArrow (#86624)

Fixes #86559.

(cherry picked from commit a7f4576ff4e296ff42b16d9d91aadf82b5ea325c)

[AMDGPU] Fix setting nontemporal in memory legalizer (#83815)

Iterator MI can advance in insertWait() but we need original instruction
to set temporal hint. Just move it before handling volatile.

[DAGCombiner] Fix miscompile bug in combineShiftOfShiftedLogic (#89616)

Ensure that the sum of the shift amounts does not overflow the
shift amount type when combining shifts in combineShiftOfShiftedLogic.

Solves a miscompile bug found when testing the C23 BitInt feature.

Targets like X86 that only use an i8 for shift amounts after
legalization seems to be extra susceptible for bugs like this as it
isn't legal to shift more than 255 steps.

(cherry picked from commit f9b419b7a038dcd51a7943b160acc867714c595f)

[DAGCombiner] Pre-commit test case for miscompile bug in combineShiftOfShiftedLogic

DAGCombiner is trying to fold shl over binops, and in the process
combining it with another shl. However it needs to be more careful
to ensure that the sum of the shift counts fits in the type used
for the shift amount.
For example, X86 is using i8 as shift amount type. So we need to
make sure that the sum of the shift amounts isn't greater than 255.

Fix will be applied in a later commit. This only pre-commits the
test case to show that we currently get the wrong result.

Bug was found when testing the C23 BitInt feature.

(cherry picked from commit 5fd9bbdea6cc248469d5465de44e747378ffafcb)

release/18.x: [clang-format] Correctly annotate braces in macros (#87953)

Backport 58323de2e5ed

[libcxx] [modules] Add _LIBCPP_USING_IF_EXISTS on aligned_alloc (#89827)

This is missing e.g. on Windows. With this change, it's possible to make
the libcxx std module work on mingw-w64 (although that requires a few
fixes to those headers).

In the regular cstdlib header, we have _LIBCPP_USING_IF_EXISTS flagged
on every single reexported function (since
a9c9183ca42629fa83cdda297d1d30c7bc1d7c91), but the modules seem to only
have _LIBCPP_USING_IF_EXISTS set on a few individual functions, so far.

(cherry picked from commit 91526d64a8adb14edc55adfd5270858791822837)

release/18.x: [clang-format] Revert breaking stream operators to previous default (#89016)

Backport 29ecd6d50f14

[analyzer] Fix performance of getTaintedSymbolsImpl() (#89606)

Previously the function
```
std::vector<SymbolRef> taint::getTaintedSymbolsImpl(ProgramStateRef State,
                                                    const MemRegion *Reg,
                                                    TaintTagType K,
                                                    bool returnFirstOnly)
```
(one of the 4 overloaded variants under this name) was handling element
regions in a highly inefficient manner: it performed the "also examine
the super-region" step twice. (Once in the branch for element regions,
and once in the more general branch for all `SubRegion`s -- note that
`ElementRegion` is a subclass of `SubRegion`.)

As pointer arithmetic produces `ElementRegion`s, it's not too difficult
to get a chain of N nested element regions where this inefficient
recursion would produce 2^N calls.

This commit is essentially NFC, apart from the performance improvements
and the removal of (probably irrelevant) duplicate entries from the
return value of `getTaintedSymbols()` calls.

Fixes #89045

(cherry picked from commit ce763bff081f8e97c7c3610ed0f15f14d60e875f)

release/18.x: [clang-format] Fix a regression in annotating BK_BracedInit (#87450)

Backport 7c9c38eaa9b7

[GlobalISel] Fix fewerElementsVectorPhi to insert after G_PHIs (#87927)

Currently the inserted mergelike instructions will be inserted at the
location of the G_PHI. Seems like the behaviour was correct before, but
the rework done in https://reviews.llvm.org/D114198 forgot to include
the part which makes sure the instructions will be inserted after all
the G_PHIs.

(cherry picked from commit 2347020e4ce62ee7c7378824dc6ad2b94917a638)

[X86] Fix miscompile in combineShiftRightArithmetic

When folding (ashr (shl, x, c1), c2) we need to treat c1 and c2
as unsigned to find out if the combined shift should be a left
or right shift.
Also do an early out during pre-legalization in case c1 and c2
has different types, as that otherwise complicated the comparison
of c1 and c2 a bit.

(cherry picked from commit 3e6e54eb795ce7a1ccd47df8c22fc08125a88886)

[X86] Pre-commit tests (NFC)

 [InstCombine] Fix unexpected overwriting in `foldSelectWithSRem` (#89539)

Fixes #89516

(cherry picked from commit 6309440c218778db027306826993e484eab2be17)

ReleaseNote: Mention SpecialCaseList change (#89141)

Co-authored-by: Paul T Robinson <paul.robinson@sony.com>

[X86] Always use 64-bit relocations in no-PIC large code model (#89101)

This matches other types of relocations, e.g. to constant pool. And
makes things more consistent with PIC large code model.

Some users of the large code model may not place small data in the lower
2GB of the address space (e.g.
https://github.com/ClangBuiltLinux/linux/issues/2016), so just
unconditionally use 64-bit relocations in the large code model.

So now functions in a section not marked large will use 64-bit
relocations to reference everything when using the large code model.

This also fixes some lldb tests broken by #88172
(https://lab.llvm.org/buildbot/#/builders/68/builds/72458).

(cherry picked from commit 6cea7c491f4c4c68aa0494a9b18f36ff40c22c81)

[analyzer] Fix a security.cert.env.InvalidPtr crash

Fixes #88181

(cherry picked from commit e096c144921daba59963f15e89d2ca6fb32d3a78)

Bump version to 18.1.5 (#89291)

[CMake][Release] Disable PGO (#88465) (#89000)

Running the test-release.sh script with PGO enabled causes build errors
like:

ld.lld: error: Function Import: link error: linking module flags
'ProfileSummary': IDs have conflicting values

I believe this a build system bug due to the PGO profile data being
generated unconditionally. If you run `ninja check-all` and then `ninja
install` like we do in test-release.sh, then the profile data is
regenerated during `ninja install` and some of the clang tools which are
not test dependencies get build during the ninja install step with
different profile data. When these tools link against the LLVM
libraries, like libSupport, we end up with these errors.

(cherry picked from commit 0d2bb7f017f13ceae793fab7d83d3e67e8d8d8f8)

[MIPS] Fix the opcode of max.fmt and mina.fmt (#85609)

- The opcode of the mina.fmt and max.fmt is documented wrong, the
  object code compiled from the same assembly with LLVM behaves
  differently than one compiled with GCC and Binutils.
- Modify the opcodes to match Binutils. The actual opcodes are as
follows:

  {5,3} | bits {2,0} of func
           |    ...   | 100  | 101    | 110   | 111
  -----+-----+-----+-----+-----+-----
   010  |   ...   |  min  | mina | max  | maxa

(cherry picked from commit 8b859c6e4a8e9ab9969582267bbdc04ed6bfa535)

Fix override keyword being print to the left side

Previously, the `override` keyword in C++ was being print in the left
side of a method decl, which is unsupported by C++ standard. This commit
fixes that by setting the `CanPrintOnLeft` field to 0, forcing it to be
print on the right side of the decl.

Signed-off-by: Giuliano Belinassi <gbelinassi@suse.de>

Revert "[Mips] Fix missing sign extension in expansion of sub-word atomic max (#77072)"

These changes caused correctness regressions observed in Rust,
see
https://github.com/llvm/llvm-project/pull/77072#issuecomment-2049009507.

This reverts commit 0e501dbd932ef1c6f4e747c83bf33beef0a09ecf.
This reverts commit fbb27d16fa12aa595cbd20a1fb5f1c5b80748fa4.

[LLD] [COFF] Don't add pseudo relocs for dangling references (#88487)

When doing GC, we normally won't have dangling references, because such
a reference would keep the other section alive, keeping it from being
eliminated.

However, references within DWARF sections are ignored for the purposes
of GC (because otherwise, they would essentially keep everything alive,
defeating the point of the GC), see
c579a5b1d92a9bc2046d00ee2d427832e0f5ddec for more context.

Therefore, dangling relocations against discarded symbols are ignored
within DWARF sections (see maybeReportRelocationToDiscarded in
Chunks.cpp). Consequently, we also shouldn't create any pseudo
relocations for these cases, as we run into a null pointer dereference
when trying to generate the pseudo relocation info for it.

This fixes the downstream bug
https://github.com/mstorsjo/llvm-mingw/issues/418, fixing crashes on
combinations with -ffunction-sections, -fdata-sections,
-Wl,--gc-sections and debug info.

(cherry picked from commit 9c970d5ecd6a85188cd2b0a941fcd4d60063ef81)

[libc++] Fix -Wgnu-include-next in stddef.h (#88214)

As reported in #86843, we must have #pragma GCC system_header before we
use #include_next, otherwise the compiler may not understand that we're
in a system header and may issue a diagnostic for our usage of

(cherry picked from commit 3c4b673af05f53e8a4d1a382b5c86367ea512c9e)

[SelectionDAG] Prevent combination on inconsistent type in `combineCarryDiamond` (#84888)

Fixes #84831
When matching carry pattern with `getAsCarry`, it may produce different
type of carryout. This patch checks such case and does early exit.

I'm new to DAG, any suggestion is appreciated.

(cherry picked from commit cb4453dc69d75064c9a82e9a6a9bf0d0ded4b204)

[RISCV] Support rv{32, 64}e in the compiler builtins (#88252)

Register spills (save/restore) in RISC-V embedded work differently
because there are less registers and different stack alignment.

[GCC equivalent
](https://github.com/gcc-mirror/gcc/blob/master/libgcc/config/riscv/save-restore.S#L298C16-L336)

Follow up from #76777.

---------

Signed-off-by: xermicus <cyrill@parity.io>
(cherry picked from commit bd32aaa8c9ec2094f605315b3989adc2a567ca98)

github-upload-release.py: Fix bug preventing release creation (#84571)

After aa02002491333c42060373bc84f1ff5d2c76b4ce we started passing the
user name to the create_release function and this was being interpreted
as the git tag.

(cherry picked from commit 0b9ce71a256d86c08f2b52ad2e337395b8f54b41)

[Codegen][X86] Fix /HOTPATCH with clang-cl and inline asm (#87639)

This fixes an edge case where functions starting with inline assembly
would assert while trying to lower that inline asm instruction.

After this PR, for now we always add a no-op (xchgw in this case) without
considering the size of the next inline asm instruction. We might want
to revisit this in the future.

This fixes Unreal Engine 5.3.2 compilation with clang-cl and /HOTPATCH.

Should close https://github.com/llvm/llvm-project/issues/56234

(cherry picked from commit ec1af63dde58c735fe60d6f2aafdb10fa93f410d)

[InstSimplify] Make sure the simplified value doesn't generate poison in threadBinOpOverSelect (#87075)

Alive2: https://alive2.llvm.org/ce/z/y_Jmdn
Fix https://github.com/llvm/llvm-project/issues/87042.

(cherry picked from commit 3197f9d8b0efc3efdc531421bd11c16305d9b1ff)

Prepend all library intrinsics with `#` when building for Arm64EC (#87542)

While attempting to build some Rust code, I was getting linker errors
due to missing functions that are implemented in `compiler-rt`. Turns
out that when `compiler-rt` is built for Arm64EC, all its function names
are mangled with the leading `#`.

This change removes the hard-coded list of library-implemented
intrinsics to mangle for Arm64EC, and instead assumes that they all must
be mangled.

[SLP]Fix a crash if the argument of call was affected by minbitwidth analysis.

Need to support proper type conversion for function arguments to avoid
compiler crash.

[libcxx] coerce formatter precision to int (#87738)

__precision_ is declared as an int32_t which on some hexagon platforms
is defined as a long.

This change fixes errors like the ones below:

In file included from
/local/mnt/workspace/hex/llvm-project/libcxx/test/libcxx/diagnostics/format.nodiscard_extensions.compile.pass.cpp:19:
In file included from
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/format:202:
In file included from
/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/format_functions.h:29:

/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/formatter_floating_point.h:700:17:
error: no matching function for call to 'max'
700 | int __p = std::max(1, (__specs.__has_precision() ?
__specs.__precision_ : 6));
          |                 ^~~~~~~~

/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/formatter_floating_point.h:771:25:
note: in instantiation of function template specialization
'std::__formatter::__format_floating_point<float, char,
std::format_context>' requested here
771 | return __formatter::__format_floating_point(__value, __ctx,
__parser_.__get_parsed_std_specifications(__ctx));
          |                         ^

/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/format_functions.h:284:42:
note: in instantiation of function template specialization
'std::__formatter_floating_point<char>::format<float,
std::format_context>' requested here
284 | __ctx.advance_to(__formatter.format(__arg, __ctx));
          |                                          ^

/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/format_functions.h:429:15:
note: in instantiation of function template specialization
'std::__vformat_to<std::back_insert_iterator<std::string>, char,
std::back_insert_iterator<std::__format::__output_buffer<char>>>'
requested here
429 | return std::__vformat_to(std::move(__out_it), __fmt, __args);
          |               ^

/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__format/format_functions.h:462:8:
note: in instantiation of function template specialization
'std::vformat_to<std::back_insert_iterator<std::string>>' requested here
      462 |   std::vformat_to(std::back_inserter(__res), __fmt, __args);
          |        ^

/local/mnt/workspace/hex/llvm-project/libcxx/test/libcxx/diagnostics/format.nodiscard_extensions.compile.pass.cpp:29:8:
note: in instantiation of function template specialization
'std::vformat<void>' requested here
       29 |   std::vformat("", std::make_format_args());
          |        ^

/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__algorithm/max.h:35:1:
note: candidate template ignored: deduced conflicting types for
parameter '_Tp' ('int' vs. 'int32_t' (aka 'long'))
35 | max(_LIBCPP_LIFETIMEBOUND const _Tp& __a, _LIBCPP_LIFETIMEBOUND
const _Tp& __b) {
          | ^

/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__algorithm/max.h:43:1:
note: candidate template ignored: could not match
'initializer_list<_Tp>' against 'int'
       43 | max(initializer_list<_Tp> __t, _Compare __comp) {
          | ^

/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__algorithm/max.h:48:86:
note: candidate function template not viable: requires single argument
'__t', but 2 arguments were provided
48 | _LIBCPP_NODISCARD_EXT inline _LIBCPP_HIDE_FROM_ABI
_LIBCPP_CONSTEXPR_SINCE_CXX14 _Tp max(initializer_list<_Tp> __t) {
| ^ ~~~~~~~~~~~~~~~~~~~~~~~~~

/local/mnt/workspace/hex/obj_runtimes_hex88_qurt_v75_ON_ON_shared/include/c++/v1/__algorithm/max.h:29:1:
note: candidate function template not viable: requires 3 arguments, but
2 were provided
29 | max(_LIBCPP_LIFETIMEBOUND const _Tp& __a, _LIBCPP_LIFETIMEBOUND
const _Tp& __b, _Compare __comp) {
| ^
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

(cherry picked from commit e1830f586ac4c504f632bdb69aab49234256e899)

[SPARC] Implement L and H inline asm argument modifiers (#87259)

This adds support for using the L and H argument modifiers for twinword
operands in inline asm code, such as in:

```
%1 = tail call i64 asm sideeffect "rd %pc, ${0:L} ; srlx ${0:L}, 32, ${0:H}", "={o4}"()
```

This is needed by the Linux kernel.

(cherry picked from commit 697dd93ae30f489e5bcdac74c2ef2d876e3ca064)

[libc++] Simplify the implementation of <stddef.h> (#86843)

Libc++'s own <stddef.h> is complicated by the need to handle various
platform-specific macros and to support duplicate inclusion. In reality,
we only need to add a declaration of nullptr_t to it, so we can simply
include the underlying <stddef.h> outside of our guards to let it handle
re-inclusion itself.

(cherry picked from commit 2950283dddab03c183c1be2d7de9d4999cc86131)

[lit][ci] Publish lit wheels (#88072)

Add wheel publishing in addition to existing source distribution
publishing of lit.

Fixes #63369. This also uses the exact fix proposed by @EFord36 in
#63369.

Signed-off-by: Schuyler Eldridge <schuyler.eldridge@sifive.com>
(cherry picked from commit 8a8ab8f70cbb5507d1aa55efcd9c6e61ad4e891c)

[clang-format] Correctly annotate braces of empty ctors/dtors (#82097)

Also reformat Polly.

Fixes #79834.

(cherry picked from commit 8de230093f585b64fcd642b46e6560131e95b394)

[Headers] Don't declare unreachable() from stddef.h in C++ (#86748)

Even if __need_unreachable is set, stddef.h should not declare
unreachable() in C++ because it conflicts with the declaration in
\<utility>.

(cherry picked from commit df69a305253f1d1b4a4066055a07101a4cc03e55)

[ConstantRange] Fix off by 1 bugs in UIToFP and SIToFP handling. (#86041)

We were passing the min and max values of the range to the ConstantRange
constructor, but the constructor expects the upper bound to 1 more than
the max value so we need to add 1.

We also need to use getNonEmpty so that passing 0, 0 to the constructor
creates a full range rather than an empty range. And passing smin,
smax+1 doesn't cause an assertion.

I believe this fixes at least some of the reason #79158 was reverted.

(cherry picked from commit 12836467b76c56872b4c22a6fd44bcda696ea720)

[Float2Int] Pre-commit test for SIToFP/UIToFP ConstantRange bug. NFC

The range for these operations is being constructed without the
maximum value for the range due to an incorrect usage of the
ConstantRange constructor.

This causes Float2Int to think the range for 'uitofp i1' only
contains 0 instead of 0 and 1.

(cherry picked from commit 6295e677220bb6ec1fa8abe2f4a94b513b91b786)

Bump version to 18.1.4 (#87715)

[clang] Avoid -Wshadow warning when init-capture named same as class field (#74512)

Shadowing warning doesn't make much sense since field is not available
in lambda's body without capturing this.

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

[tsan] Refine fstat{,64} interceptors (#86625)

In glibc versions before 2.33. `libc_nonshared.a` defines
`__fxstat/__fxstat64` but there is no `fstat/fstat64`. glibc 2.33 added
`fstat/fstat64` and obsoleted `__fxstat/__fxstat64`. Ports added after
2.33 do not provide `__fxstat/__fxstat64`, so our `fstat/fstat64`
interceptors using `__fxstat/__fxstat64` interceptors would lead to
runtime failures on such ports (LoongArch and certain RISC-V ports).

Similar to https://reviews.llvm.org/D118423, refine the conditions that
we define fstat{,64} interceptors. `fstat` is supported by musl/*BSD
while `fstat64` is glibc only.

(cherry picked from commit d5224b73ccd09a6759759791f58426b6acd4a2e2)

[clang][Sema] Fix a CTAD regression after 42239d2e9 (#86914)

The most recent declaration of a template as a friend can introduce a
different template parameter depth compared to what we anticipate from a
CTAD guide.

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

[mlir][transform] replace original op to loop ops (#83537)

(cherry picked from commit 0597644a6466ae9148b0b41cb8f95d5022e045c2)

[OpenMP][AIX] Affinity implementation for AIX (#84984)

This patch implements `affinity` for AIX, which is quite different from
platforms such as Linux.
- Setting CPU affinity through masks and related functions are not
supported. System call `bindprocessor()` is used to bind a thread to one
CPU per call.
- There are no system routines to get the affinity info of a thread. The
implementation of `get_system_affinity()` for AIX gets the mask of all
available CPUs, to be used as the full mask only.
- Topology is not available from the file system. It is obtained through
system SRAD (Scheduler Resource Allocation Domain).

This patch has run through the libomp LIT tests successfully with
`affinity` enabled.

(cherry picked from commit d394f3a162b871668d0c8e8bf6a94922fa8698ae)

[Support] Fix color handling in formatted_raw_ostream (#86700)

The color methods in formatted_raw_ostream were forwarding directly to
the underlying stream without considering existing buffered output. This
would cause incorrect colored output for buffered uses of
formatted_raw_ostream.

Fix this issue by applying the color to the formatted_raw_ostream itself
and temporarily disabling scanning of any color related output so as not
to affect the position tracking.

This fix means that workarounds that forced formatted_raw_ostream
buffering to be disabled can be removed. In the case of llvm-objdump,
this can improve disassembly performance when redirecting to a file by
more than an order of magnitude on both Windows and Linux. This
improvement restores the disassembly performance when redirecting to a
file to a level similar to before color support was added.

(cherry picked from commit c9db031c48852af491747dab86ef6f19195eb20d)

Reapply [libcxx] [modules] Fix relative paths with absolute LIBCXX_INSTALL_MODULES_DIR (#86020)

This reapplies 272d1b44efdedb68c194970a610f0ca1b7b769c5 (from #85756),
which was reverted in
407937036fa7640f61f225474b1ea6623a40dbdd.

In the previous attempt, empty CMAKE_INSTALL_PREFIX was handled by
quoting them, in d209d1340b99d4fbd325dffb5e13b757ab8264ea. That made the
calls to cmake_path(ABSOLUTE_PATH) succeed, but the output paths of that
weren't actually absolute, which was required by file(RELATIVE_PATH).

Avoid this issue by constructing a non-empty base directory variable
to use for calculating the relative path.

(cherry picked from commit 50801f1095d33e712c3a51fdeef82569bd09007f)

 release/18.x: [SystemZ] Fix overflow flag for i128 USUBO (#86491)

We use the VSCBIQ/VSBIQ/VSBCBIQ family of instructions to implement
USUBO/USUBO_CARRY for the i128 data type. However, these instructions
use an inverted sense of the borrow indication flag (a value of 1
indicates *no* borrow, while a value of 0 indicated borrow). This does
not match the semantics of the boolean "overflow" flag of the
USUBO/USUBO_CARRY ISD nodes.

Fix this by generating code to explicitly invert the flag. These cancel
out of the result of USUBO feeds into an USUBO_CARRY.

To avoid unnecessary zero-extend operations, also improve the DAGCombine
handling of ZERO_EXTEND to optimize (zext (xor (trunc))) sequences where
appropriate.

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

[lld/ELF][X86] Respect outSecOff when checking if GOTPCREL can be relaxed (#86334)

The existing implementation didn't handle when the input text section
was some offset from the output section.

This resulted in an assert in relaxGot() with an lld built with asserts
for some large binaries, or even worse, a silently broken binary with an
lld without asserts.

(cherry picked from commit 48048051323d5dd74057dc5f32df8c3c323afcd5)

[ODS][NFC] Cast range.size() to int32_t in accumulation (#85629)

Using range.size() "as is" means we accumulate 'size_t' values into
'int32_t' variable. This may produce narrowing conversion warnings
(particularly, on MSVC). The surrounding code seems to cast <x>.size()
to 'int32_t' so following this practice seems safe enough.

Co-authored-by: Ovidiu Pintican <ovidiu.pintican@intel.com>
(cherry picked from commit bce17034157fdfe4d898d30366c1eeca3442fa3d)

[Mips] Restore wrong deletion of instruction 'and' in unsigned min/max processing. (#85902)

Fix #61881

(cherry picked from commit 5d7fd6a04a6748936dece9d90481b2ba4ec97e53)

[Mips] Fix missing sign extension in expansion of sub-word atomic max (#77072)

Add sign extension "SEB/SEH" before compare.

Fix #61881

(cherry picked from commit 755b439694432d4f68e20e979b479cbc30602bb1)

[PowerPC] provide CFI for ELF32 to unwind cr2, cr3, cr4 (#83098)

Delete the code that skips the CFI for the condition register on ELF32.
The code checked !MustSaveCR, which happened only when
Subtarget.is32BitELFABI(), where spillCalleeSavedRegisters is spilling
cr in a different way. The spill was missing CFI. After deleting this
code, a spill of cr2 to cr4 gets CFI in the same way as a spill of r14
to r31.

Fixes #83094

(cherry picked from commit 6b70c5d79fe44cbe01b0443454c6952c5b541585)

[NFC][PowerPC] use script to regenerate the CHECK lines

(cherry picked from commit 3196005f6bedbed61a86626a9e4f8fee7437a914)

[msan] Re-exec with no ASLR if memory layout is incompatible on Linux (#85142)

This ports the change from TSan
(https://github.com/llvm/llvm-project/commit/0784b1eefa36d4acbb0dacd2d18796e26313b6c5).

Testing notes: run 'sudo sysctl vm.mmap_rnd_bits=32; ninja check-msan'
before and after this patch.

N.B. aggressive ASLR may also cause the app to overlap with the
allocator region; for MSan, this was fixed in
https://github.com/llvm/llvm-project/commit/af2bf86a372cacf5f536bae06e2f2d3886eefb7b

(cherry picked from commit 58f7251820b14c93168726a24816d8a094599be5)

[msan] Add 'MappingDesc::ALLOCATOR' type and check it is available (#85153)

MSan divides the virtual address space into APP, INVALID, SHADOW and
ORIGIN memory. The allocator usually just steals a bit of the APP
address space: typically the bottom portion of the PIE binaries section,
which works because the Linux kernel maps from the top of the PIE
binaries section. However, if ASLR is very aggressive, the binary may
end up mapped in the same location where the allocator wants to live;
this results in a segfault.

This patch adds in a MappingDesc::ALLOCATOR type and enforces that the
memory range for the allocator is not occupied by anything else.

Since the allocator range information is not readily available in
msan.h, we duplicate the information from msan_allocator.cpp.

Note: aggressive ASLR can also lead to a different type of failure,
where the PIE binaries/libraries are mapped entirely outside of the
APP/ALLOCATOR sections; that will be addressed in a separate patch
(https://github.com/llvm/llvm-project/pull/85142).

(cherry picked from commit af2bf86a372cacf5f536bae06e2f2d3886eefb7b)

[clang][CodeGen] Allow `memcpy` replace with trivial auto var init

When emitting the storage (or memory copy operations) for constant
initializers, the decision whether to split a constant structure or
array store into a sequence of field stores or to use `memcpy` is
based upon the optimization level and the size of the initializer.
In afe8b93ffdfef5d8879e1894b9d7dda40dee2b8d, we extended this by
allowing constants to be split when the array (or struct) type does
not match the type of data the address to the object (constant) is
expected to contain. This may happen when `emitStoresForConstant` is
called by `EmitAutoVarInit`, as the element type of the address gets
shrunk. When this occurs, let the initializer be split into a bunch
of stores only under `-ftrivial-auto-var-init=pattern`.

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

[LoongArch] Assume no-op addrspacecasts by default (#82332)

This PR indicates that `addrspacecasts` are always no-ops on LoongArch.

Fixes #82330

(cherry picked from commit dd3e0a4643670f33850278ad281a358bbdd04e92)

[SROA]: Only defer trying partial sized ptr or ptr vector types

Change-Id: Ic77f87290905addadd5819dff2d0c62f031022ab
(cherry picked from commit 1e828f838cc0f15074f3dbbb04929c06ef0c9729)

[ARM] Update IsRestored for LR based on all returns (#82745)

PR #75527 fixed ARMFrameLowering to set the IsRestored flag for LR based
on all of the return instructions in the function, not just one.
However, there is also code in ARMLoadStoreOptimizer which changes
return instructions, but it set IsRestored based on the one instruction
it changed, not the whole function.

The fix is to factor out the code added in #75527, and also call it from
ARMLoadStoreOptimizer if it made a change to return instructions.

Fixes #80287.

(cherry picked from commit 749384c08e042739342c88b521c8ba5dac1b9276)

Pre-commit test showing bug #80287

This test shows the bug where LR is used as a general-purpose register
on a code path where it is not spilled to the stack.

(cherry picked from commit 8779cf68e80dcc0b15e8034f39e6ce18b08352b6)

Bump version to 18.1.3 (#86168)

[X86] Add missing subvector_subreg_lowering for BF16 (#83720)

[C++20] [Moduls] Avoid computing odr hash for functions from comparing constraint expression

Previously we disabled to compute ODR hash for declarations from the
global module fragment. However, we missed the case that the functions
lives in the concept requiments (see the attached the test files for
example). And the mismatch causes the potential crashment.

Due to we will set the function body as lazy after we deserialize it and
we will only take its body when needed. However, we don't allow to take
the body during deserializing. So it is actually potentially problematic
if we set the body as lazy first and computing the hash value of the
function, which requires to deserialize its body. So we will meet a
crash here.

This patch tries to solve the issue by not taking the body of the
function from GMF. Note that we can't skip comparing the constraint
expression from the GMF directly since it is an key part of the
function selecting and it may be the reason why we can't return 0
directly for `FunctionDecl::getODRHash()` from the GMF.

[RISCV] Fix mgather -> riscv.masked.strided.load combine not extending indices (#82506)

This fixes the miscompile reported in #82430 by telling
isSimpleVIDSequence to sign extend to XLen instead of the width of the
indices, since the "sequence" of indices generated by a strided load
will be at XLen.

This was the simplest way I could think of getting isSimpleVIDSequence
to treat the indexes as if they were zero extended to XLenVT.

Another way we could do this is by refactoring out the "get constant
integers" part from isSimpleVIDSequence and handle them as APInts so we
can separately zero extend it.

Fixes #82430

(cherry picked from commit 815644b4dd882ade2e5649d4f97c3dd6f7aea200)

[RISCV] Adjust test case to show wrong stride. NFC

See https://github.com/llvm/llvm-project/pull/82506#discussion_r1498080785

(cherry picked from commit 11d115d0569b212dfeb7fe6485be48070e068e19)

[RISCV] Add test case for miscompile in gather -> strided load combine. NFC

This shows the issue in #82430, but triggers it via the widening SEW combine
rather than a GEP that RISCVGatherScatterLowering doesn't detect.

(cherry picked from commit 2cd59bdc891ab59a1abfe5205feb45791a530a47)

[TSan] Fix atomicrmw xchg with pointer and floats (#85228)

atomicrmw xchg also accepts pointer and floating-point values. To handle
those, insert necessary casts to and from integer. This is what we do
for cmpxchg as well.

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

(cherry picked from commit ff2fb2a1d78585944dcdb9061c8487fe1476dfa4)

[AVR] Remove earlyclobber from LDDRdPtrQ (#85277)

LDDRdPtrQ was marked as `earlyclobber`, which doesn't play well with
GreedyRA (which can generate this instruction through `loadRegFromStackSlot()`).

This seems to be the same case as:

https://github.com/llvm/llvm-project/blob/a99b912c9b74f6ef91786b4dfbc25160c27d3b41/llvm/lib/Target/AVR/AVRInstrInfo.td#L1421

Closes https://github.com/llvm/llvm-project/issues/81911.

Revert "release/18.x: [openmp] __kmp_x86_cpuid fix for i386/PIC builds. (#846…"

This reverts commit 9b3edb592debc00a5c3fbf7a71f63e07d6af44be.

[PowerPC] Update chain uses when emitting lxsizx (#84892)

(cherry picked from commit e5b20c83e5ba25e6e0650df30352ce54c2f6ea2f)

[llvm-shlib] Fix the version naming style of libLLVM for Windows (#85710)

This reverts the changes from 91a384621e5b762d9c173ffd247cfeadd5f436a2
for Windows targets. The changes in that commit don't work as expected
for Windows targets (those parts of llvm_add_library don't quite behave
the same for Windows), while the previous status quo (producing a
library named "libLLVM-<major>.dll") is the defacto standard way of
doing versioned library names there, contrary to on Unix.

After that commit, the library always ended up named "libLLVM.dll",
executables linking against it would reference "libLLVM.dll", and
"libLLVM-<major>.dll" was provided as a symlink.

Thus revert this bit back to as it were, so that executables actually
link against a versioned libLLVM, and no separate symlink is needed.

The only thing that might be improved compared to the status quo as it
was before these changes, is that the import library is named
"lib/libLLVM-<major>.dll.a", while the common style would be to name it
plainly "lib/libLLVM.dll.a" (even while it produces references to
"libLLVM-<major>.dll", but none of these had that effect for Windows
targets.

(As a side note, the llvm-shlib library can be built for MinGW, but not
currently in MSVC configurations.)

(cherry picked from commit cb2ca23345d3d9bde027a18d301949e8bdf606a6)

[llvm-shlib] Fix libLLVM-18 symlink on mingw (#85554)

The TARGET_SONAME_FILE_NAME generator expression is not available on dll
target platforms.

(cherry picked from commit f84980570d3f85bdf5c9432647c05bae04a735a0)

llvm-shlib: Fix libLLVM-${MAJOR}.so symlink on MacOS (#85163)

This is a partial revert of 10c48a772742b7afe665a815b7eba2047f17dc4b
with a fix for the symlink target name on MacOS

See #84637

(cherry picked from commit ec2b7522dbee1cb91111d6ade6e1768462247dcf)

[WebAssembly] Change the default linker for `wasm32-wasip2` (#84569)

This commit changes the default linker in the WebAssembly toolchain for
the `wasm32-wasip2` target. This target is being added to the
WebAssembly/wasi-sdk and WebAssembly/wasi-libc projects to target the
Component Model by default, in contrast with the preexisting
`wasm32-wasi` target (in the process of being renamed to
`wasm32-wasip1`) which outputs a core WebAssembly module by default.

The `wasm-component-ld` project currently lives in my GitHub account at
https://github.com/alexcrichton/wasm-component-ld and isn't necessarily
"official" yet, but it's expected to continue to evolve as the
`wasm32-wasip2` target continues to shape up and evolve.

(cherry picked from commit d66121d74a458e098511b9de920d815440acaa1b)

workflows: Fix baseline version for llvm abi checks (#85166)

The baseline version calculations was assuming the minor release would
always be 0.

(cherry picked from commit d93363a0e803a9fb2889ff03237f4e93aacf0108)

[InstCombine] Drop UB-implying attrs/metadata after speculating an instruction (#85542)

When speculating an instruction in `InstCombinerImpl::FoldOpIntoSelect`,
the call may result in undefined behavior. This patch drops all
UB-implying attrs/metadata to fix this.

Fixes #85536.

(cherry picked from commit 252d01952c087cf0d141f7f281cf60efeb98be41)

[lld][LoongArch] Fix handleUleb128

(cherry picked from commit a41bcb3930534ef1525b4fc30e53e818b39e2b60)

[lld][test] Fix sanitizer buildbot failure

Buildbot failure:
https://lab.llvm.org/buildbot/#/builders/5/builds/41530/steps/9/logs/stdio

(cherry picked from commit d9b435c24ddddcc8148fd97b42f6bb1124e52307)

Remove support for EXPORTAS in def files to maintain ABI compatibility for COFFShortExport

[Arm64EC] Copy import descriptors to the EC Map (#84834)

As noted in <https://github.com/llvm/llvm-project/pull/78537>, MSVC
places import descriptors in both the EC and regular map - that PR moved
the descriptors to ONLY the regular map, however this causes linking
errors when linking as Arm64EC:

```
bcryptprimitives.lib(bcryptprimitives.dll) : error LNK2001: unresolved external symbol __IMPORT_DESCRIPTOR_bcryptprimitives (EC Symbol)
```

This change copies import descriptors from the regular map to the EC
map, which fixes this linking error.

[llvm-lib][Object] Add support for EC importlib symbols. (#81059)

ARM64EC import libraries expose two additional symbols: mangled thunk
symbol (like `#func`) and auxiliary import symbol (like`__imp_aux_func`).
The main functional change with this patch is that those symbols are
properly added to static library ECSYMBOLS.

[llvm-lib][llvm-dlltool][Object] Add support for EXPORTAS name types. (#78772)

EXPORTAS is a new name type in import libraries. It's used by default on ARM64EC,
but it's allowed on other platforms as well.