[NFC] Minor documentation fix for the release branch

[clang][docs] Release notes for C/C++ SVE Operators

[Sparc] Don't use SunStyleELFSectionSwitchSyntax

As discussed in D85414 <https://reviews.llvm.org/D85414>, two tests
currently `FAIL` on Sparc since that backend uses the Sun assembler syntax
for the `.section` directive, controlled by
`SunStyleELFSectionSwitchSyntax`.

Instead of adapting the affected tests, this patch changes that default.
The internal assembler still accepts both forms as input, only the output
syntax is affected.

Current support for the Sun syntax is cursory at best: the built-in
assembler cannot even assemble some of the directives emitted by GCC, and
the set supported by the Solaris assembler is even larger: SPARC Assembly
Language Reference Manual, 3.4 Pseudo-Op Attributes
<https://docs.oracle.com/cd/E37838_01/html/E61063/gmabi.html#scrolltoc>.

A few Sparc test cases need to be adjusted. At the same time, the patch
fixes the failures from D85414 <https://reviews.llvm.org/D85414>.

Tested on `sparcv9-sun-solaris2.11`.

Differential Revision: https://reviews.llvm.org/D85415

(cherry picked from commit d9993484ee40abaab6d9e96872d3a29044202aea)

[InstCombine] Correct strtol folding with nonnull endptr

Reflect in the pointer's offset the length of the leading part
of the consumed string preceding the first converted digit.

Reviewed By: efriedma

Differential Revision: https://reviews.llvm.org/D130912

(cherry picked from commit bcef4d238d113c61127575bf5dd0328f97bda9e9)

[mlir][test] Require JIT support in JIT tests

A number of mlir tests `FAIL` on Solaris/sparcv9 with `Target has no JIT
support`.  This patch fixes that by mimicing `clang/test/lit.cfg.py` which
implements a `host-supports-jit` keyword for this.  The gtest-based unit
tests don't support `REQUIRES:`, so lack of support needs to be hardcoded
there.

Tested on `amd64-pc-solaris2.11` (`check-mlir` results unchanged) and
`sparcv9-sun-solaris2.11` (only one unrelated failure left).

Differential Revision: https://reviews.llvm.org/D131151

(cherry picked from commit ca98e0dd6cf59907f07201c4282dcafeeea11a91)

[clang][RISCV] Fix incorrect ABI lowering for inherited structs under hard-float ABIs

The hard float ABIs have a rule that if a flattened struct contains
either a single fp value, or an int+fp, or fp+fp then it may be passed
in a pair of registers (if sufficient GPRs+FPRs are available).
detectFPCCEligibleStruct and the helper it calls,
detectFPCCEligibleStructHelper examine the type of the argument/return
value to determine if it complies with the requirements for this ABI
rule.

As reported in bug #57084, this logic produces incorrect results for C++
structs that inherit from other structs. This is because only the fields
of the struct were examined, but enumerating RD->fields misses any
fields in inherited C++ structs. This patch corrects that issue by
adding appropriate logic to enumerate any included base structs.

Differential Revision: https://reviews.llvm.org/D131677

(cherry picked from commit bc538320809fb52af12ec0366118c82201af4f40)

[clang][RISCV][test] Add test that shows incorrect ABI lowering

As reported in <https://github.com/llvm/llvm-project/issues/57084>,
under hard float ABIs there are issues with lowering structs that
inherit from other structs.

See <https://reviews.llvm.org/D131677> for a fix.

(cherry picked from commit d17de5479c6234f9e37fb4deca9e537bf8d3932e)

[SDAG] avoid generating libcall to function with same name

This is a potentially better alternative to D131452 that also
should avoid the infinite loop bug from:
issue #56403

This is again a minimal fix to reduce merging pain for the
release. But if this makes sense, then we might want to guard
all of the RTLIB generation (and other libcalls?) with a
similar name check.

Differential Revision: https://reviews.llvm.org/D131521

(cherry picked from commit 7f72a0f5bb3743428021df920d9a7c50f74f61ae)

[AArch64] add test for recursive libcall lowering; NFC

Issue #56403

(cherry picked from commit 8eddd1ec6066fe958313a2b1cc4907b5ee7dfbee)

workflows/llvm-project-tests: Workaround an issue with lldb builds on Windows

For some reason cmake started selecting a 32-bit version of python on
Windows instead of the 64-bit version when building windows.  Explicitly
setting the default python to 3.10 fixes this problem.

Reviewed By: thieta

Differential Revision: https://reviews.llvm.org/D132280

(cherry picked from commit 99020b3c73c1e22fa388be8fd0c44391d40b3a38)

workflows/version-check: Fix check for release candidates

Reviewed By: thieta

Differential Revision: https://reviews.llvm.org/D131650

(cherry picked from commit 5b108dfc159a461c10bba1fd1f05308bf57dcd25)

[clangd] Fix an inlay-hint crash on a broken designator.

Differential Revision: https://reviews.llvm.org/D131696

(cherry picked from commit 06b97b4985ad0415f6cde4baad2bc7d73b456244)

[flang] Add Solaris/x86 support to Optimizer/CodeGen/Target.cpp

When testing LLVM 15.0.0 rc1 on Solaris, I found that 50+ flang tests
`FAIL`ed with

  error:
/vol/llvm/src/llvm-project/local/flang/lib/Optimizer/CodeGen/Target.cpp:310:
not yet implemented: target not implemented

This patch fixes that for Solaris/x86, where the fix is trivial (just
handling it like the other x86 OSes).

Tested on `amd64-pc-solaris2.11`; only a single failure remains now.

Differential Revision: https://reviews.llvm.org/D131054

(cherry picked from commit bcb2740f415b0f825402f656dda3271414121a0e)

[MC] Avoid C++17 structured bindings

release/15.x uses C++14 and structured bindings trigger warnings in Clang/GCC
and errors in MSVC.

[llvm] [cmake] Move LLVM_INSTALL_PACKAGE_DIR top-level to fix llvm-config

Move the `LLVM_INSTALL_PACKAGE_DIR` declaration from llvm/cmake/modules
directory to the top-level llvm/CMakeLists.txt, in order to fix
the regression in `llvm-config --cmakedir` output for installed LLVM.
Since the tools directory is processed by CMake prior to
llvm/cmake/modules, the llvm-config executable ended up using
the variable prior to it being defined and incorrectly used an empty
path, resulting in e.g.:

    $ llvm-config --cmakedir
    /usr/lib/llvm/16/

With this patch, the path is defined (and therefore the default value
is being set) prior to adding the tools subdirectory and llvm-config
starts working correctly:

    $ llvm-config --cmakedir
    /usr/lib/llvm/16/lib64/cmake/llvm

This fixes a regression introduced by D130539.  Thanks to Petr Polezhaev
for reporting the problem @ https://bugs.gentoo.org/865165

Differential Revision: https://reviews.llvm.org/D131878

(cherry picked from commit d230055234863aafe63489f9ab95e52d2c1883f2)

[clang][SVE] Undefine preprocessor macro defined in

arm_sve.h defines and uses __ai macro which needs to be undefined (as it is
already in arm_neon.h).

Reviewed By: paulwalker-arm

Differential Revision: https://reviews.llvm.org/D131580

(cherry picked from commit 48e1250a91d244741c8677fed248ace1fcd7c41c)

[DAG] Ensure more Legal BUILD_VECTOR elements types in shuffle->And combine

This is a followup to D131350, which caused another problem for i64
types being split into i32 on i32 targets. This patch tries to make sure
that either Illegal types are OK, or that the element types of a
buildvector are legal and bigger than or equal to the size of the
original elements.

Differential Revision: https://reviews.llvm.org/D131883

(cherry picked from commit dfc95bab078297b1564c1ac757b1ac093d125b2d)

[flang] Install runtime libs with the toolchain

Make sure that FortranDecimal, FortranRuntime and Fortran_main are
installed/packaged even when LLVM_INSTALL_TOOLCHAIN_ONLY is enabled.
They are used by flang to link executables, so they should be provided
even with minimal installs.

Differential Revision: https://reviews.llvm.org/D131670

(cherry picked from commit 467abac2046d037f8d4cf428e76b77e5b06c187f)

[RISCV] isImpliedByDomCondition returns an Optional<bool> not a bool.

We were incorrectly checking that it returned an implicaton result,
not that the implication result itself was true.

[DebugInfo] -fdebug-prefix-map: handle '#line "file"' for asm source

`getContext().setMCLineTableRootFile` (from D62074) sets `RootFile.Name` to
`FirstCppHashFilename`. `RootFile.Name` is not processed by -fdebug-prefix-map
and will go to DW_TAG_compile_unit's DT_AT_name and DW_TAG_label's
DW_AT_decl_file. Remap `RootFile.Name`.

Fix another issue reported by https://github.com/llvm/llvm-project/issues/56609

Reviewed By: #debug-info, dblaikie, raj.khem

Differential Revision: https://reviews.llvm.org/D131848

(cherry picked from commit d797c2ffdb591d10de2964907962aaacb2e360ca)

[DebugInfo] Don't join DW_AT_comp_dir and directories[0] for DWARF v5 line tables

DWARF v5 6.2.4 The Line Number Program Header says:

> The first entry is the current directory of the compilation. Each additional
> path entry is either a full path name or is relative to the current directory of
> the compilation.

When forming a path, relative DW_AT_comp_dir and directories[0] are not supposed
to be joined together. Fix getFileNameByIndex to special case DWARF v5 DirIdx == 0.

Reviewed By: #debug-info, dblaikie

Differential Revision: https://reviews.llvm.org/D131804

(cherry picked from commit 3329cec2f79185bafd678f310fafadba2a8c76d2)

[MCDwarf] Respect -fdebug-prefix-map= for generated assembly debug info (DWARF v5)

For generated assembly debug info, MCDwarfLineTableHeader::CompilationDir is an
unmapped path set in MCContext::setGenDwarfRootFile. Remap it.

A relative destination path of -fdebug-prefix-map= exposes a llvm-dwarfdump bug
which joins relative DW_AT_comp_dir and directories[0].

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

Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D131749

(cherry picked from commit f62e60fb238146113f84e0efb1a2ebc52f05cc0a)

[BOLT] Use Optional::emplace to avoid move assignment. NFC

(cherry picked from commit 53113515cdaa19a86e4b807808b7b99dc1c91685)

[MCDwarf][test] Improve debug-prefix-map.s

(cherry picked from commit d561907f27d721558e4372990ca52a8284b7aafc)

[MCDwarf] Use emplace to avoid move assignment. NFC

(cherry picked from commit b0c4cd35df89479ec152c1f79e18d0264dd276cc)

[DAGCombine] Check zext legality in zext-extract-extend combine

Discussed in D131503.

Fix to D130782.

(cherry picked from commit 898699831b5490d88b993593e5cb415fb2d1983a)

[libcxx] [doc] Remove a leftover tentative release note

This release note was added tentatively in
https://reviews.llvm.org/D120982 / ebde6fc23bc0ee9d022fcd26b52bc82dfb7c8468.
The issue was resolved differently in
https://reviews.llvm.org/D125715 / bedf657d0f4c54ffe9ef4303382657a74296b544,
but that commit forgot to remove the tentative release note.

 __has_trivial_copy should map to __is_trivially_copyable

Found during clang 15 RC1 testing due to the new diagnostic added by @royjacobson since clang 14.  Uncertain if this fix meets the bar to also be applied to the release branch.

If accepted, I'll need someone with commit access to submit on my behalf.

Reviewed By: royjacobson, aaron.ballman, erichkeane

Differential Revision: https://reviews.llvm.org/D131730

(cherry picked from commit 64f0f7e6460019a38fe2f1cbe4b9446a3268af18)

[X86][FP16] Promote FP16->[U]INT to FP16->FP32->[U]INT

This is to avoid f16->i64 being lowered to `__fixhfdi/__fixunshfdi` on 32-bits since neither libgcc nor compiler-rt provide them. https://godbolt.org/z/cjWEsea5v

It also helps to improve the performance by promoting the vector type.

Reviewed By: LuoYuanke

Differential Revision: https://reviews.llvm.org/D131828

(cherry picked from commit 8b69549dc5c5fa0f5f8632cde1c740bb2c7d8957)

[X86][FP16] Fix vector_shuffle and lowering without f16c feature problems

The problem Alexander reported on D127982 was caused by an optimization
for AVX512-FP16 instruction. We must limit it to the feature enabled only.

During the investigation, I found we didn't expand for fp_round/fp_extend
without F16C. This may result runtime crash, so change them too.

Reviewed By: RKSimon

Differential Revision: https://reviews.llvm.org/D130817

(cherry picked from commit 23021d4d8c6b2c7cbb3ebe1be61cface0c52f80a)

[clang-tidy][docs] Fixed page title for abseil-no-internal-dependencies check documentation

It seems that documentation for abseil-no-internal-dependencies has invalid title.
This can be checked by looking at the actual web-site - https://clang.llvm.org/extra/clang-tidy/checks/abseil/no-internal-dependencies.html
There is redundant "subl.. title:: clang-tidy - abseil-no-internal-dependencies" paragraph in the beginning.

Reviewed By: njames93, sylvestre.ledru

Differential Revision: https://reviews.llvm.org/D131590

(cherry picked from commit 6c7b049f6eb78edf83506a858c7b211a7c70afd8)

[X86] Add RDPRU instruction CPUID bit masks

As mentioned on D128934 - we weren't including the CPUID bit handling for the RDPRU instruction

AMD's APMv3 (24594) lists it as CPUID Fn8000_0008_EBX Bit#4

(cherry picked from commit 08a880509e4f7ca8d346dce42fe7528c3a33f22c)

[clang][X86] Add RDPRU predefined macro tests for znver2/znver3 targets

These were missed in D128934

(cherry picked from commit 6e19e6ce36e44554ac9fbf8b2780de05e922c849)

[libcxx] [test] Fix max_size.pass.cpp for PowerPC targets

This patch fixes the max_size.pass.cpp test for PowerPC targets, depending on
endianness.

We will exhibit the full_size() behaviour for little endian
(where __endian_factor = 2 ), and the half_size() behaviour for
big endian (where __endian_factor = 1).

Differential Revision: https://reviews.llvm.org/D131682

(cherry picked from commit e2e9e2ce8efd12f0f2b7a12be113d4241706ddf2)

[OpenMP][FIX] Ensure __kmpc_kernel_parallel is reachable

The problem is we create the call to __kmpc_kernel_parallel in the
openmp-opt pass but while we optimize the code, the call is not there
yet. Thus, we assume we never reach it from __kmpc_target_deinit. That
allows us to remove the store in there (`ParallelRegionFn = nullptr`),
which leads to bad results later on.

This is a shortstop solution until we come up with something better.

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

(cherry picked from commit a8cda3290944687b4fd0138e63cd980ea497a438)

[Clang][OpenMP] Fix the issue that `llvm.lifetime.end` is emitted too early for variables captured in linear clause

Currently if an OpenMP program uses `linear` clause, and is compiled with
optimization, `llvm.lifetime.end` for variables listed in `linear` clause are
emitted too early such that there could still be uses after that. Let's take the
following code as example:
```
// loop.c
int j;
int *u;

void loop(int n) {
  int i;
  for (i = 0; i < n; ++i) {
    ++j;
    u = &j;
  }
}
```
We compile using the command:
```
clang -cc1 -fopenmp-simd -O3 -x c -triple x86_64-apple-darwin10 -emit-llvm loop.c -o loop.ll
```
The following IR (simplified) will be generated:
```
@j = local_unnamed_addr global i32 0, align 4
@u = local_unnamed_addr global ptr null, align 8

define void @loop(i32 noundef %n) local_unnamed_addr {
entry:
  %j = alloca i32, align 4
  %cmp = icmp sgt i32 %n, 0
  br i1 %cmp, label %simd.if.then, label %simd.if.end

simd.if.then:                                     ; preds = %entry
  call void @llvm.lifetime.start.p0(i64 4, ptr nonnull %j)
  store ptr %j, ptr @u, align 8
  call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
  %0 = load i32, ptr %j, align 4
  store i32 %0, ptr @j, align 4
  br label %simd.if.end

simd.if.end:                                      ; preds = %simd.if.then, %entry
  ret void
}
```
The most important part is:
```
  call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
  %0 = load i32, ptr %j, align 4
  store i32 %0, ptr @j, align 4
```
`%j` is still loaded after `@llvm.lifetime.end.p0(i64 4, ptr nonnull %j)`. This
could cause the backend incorrectly optimizes the code and further generates
incorrect code. The root cause is, when we emit a construct that could have
`linear` clause, it usually has the following pattern:
```
EmitOMPLinearClauseInit(S)
{
  OMPPrivateScope LoopScope(*this);
  ...
  EmitOMPLinearClause(S, LoopScope);
  ...
  (void)LoopScope.Privatize();
  ...
}
EmitOMPLinearClauseFinal(S, [](CodeGenFunction &) { return nullptr; });
```
Variables that need to be privatized are added into `LoopScope`, which also
serves as a RAII object. When `LoopScope` is destructed and if optimization is
enabled, a `@llvm.lifetime.end` is also emitted for each privatized variable.
However, the writing back to original variables in `linear` clause happens after
the scope in `EmitOMPLinearClauseFinal`, causing the issue we see above.

A quick "fix" seems to be, moving `EmitOMPLinearClauseFinal` inside the scope.
However, it doesn't work. That's because the local variable map has been updated
by `LoopScope` such that a variable declaration is mapped to the privatized
variable, instead of the actual one. In that way, the following code will be
generated:
```
  %0 = load i32, ptr %j, align 4
  store i32 %0, ptr %j, align 4
  call void @llvm.lifetime.end.p0(i64 4, ptr nonnull %j)
```
Well, now the life time is correct, but apparently the writing back is broken.

In this patch, a new function `OMPPrivateScope::restoreMap` is added and called
before calling `EmitOMPLinearClauseFinal`. This can make sure that
`EmitOMPLinearClauseFinal` can find the orignal varaibls to write back.

Fixes #56913.

Reviewed By: ABataev

Differential Revision: https://reviews.llvm.org/D131272

(cherry picked from commit e21202dac18ed7f718d26a0e131f96b399b4891c)

[clang][AArch64][SVE] Change SVE_VECTOR_OPERATORS macro for VLA vectors

The __ARM_FEATURE_SVE_VECTOR_OPERATORS macro should be changed to
indicate that this feature is now supported on VLA vectors as well as
VLS vectors. There is a complementary PR to the ACLE spec here
https://github.com/ARM-software/acle/pull/213

Reviewed By: peterwaller-arm

Differential Revision: https://reviews.llvm.org/D131573

(cherry picked from commit 13a784f368ef062a7bd652829bcf8bbdd94dc659)

[clang][AArch64][SVE] Clarify documentation for sizeof operator on SVE

Previously the table in LanguageExtensions said that sizeof worked on
SVE types but this is only correct for fixed-length vectors so a
clarification has been added.

(cherry picked from commit bbb30bd54a6447702f9f59a2ae4c478eb7133ae0)

[clang] Correct documentation for NEON and SVE operator support

Previously the language extension documentation didn't mention SVE and
was incomplete in listing the C/C++ operators supported on NEON. This
corrects the documentation to be in line with the implementation.

(cherry picked from commit e4642d78a89930720bc84a4775614c45327bc0dc)

[clang][AArch64][SVE] Add unary +/- operators for SVE types

This patch enables the unary promotion and negation operators on
SVE types.

Differential Revision: https://reviews.llvm.org/D130984

(cherry picked from commit 286d59ef6f7118c8a0600f3d281593700528a5d3)

Fix assert during the call to getCanonicalDecl.
https://github.com/llvm/llvm-project/issues/56884

The root problem is in isOpenMPRebuildMemberExpr, it is only need to rebuild
for field expression.  No need for member function call.

The fix is to check field for member expression and skip rebuild for member
function call.

Differential Revision: https://reviews.llvm.org/D131024

(cherry picked from commit a7bca18bc50cd2483fded0c77706980b2721ce6a)

[mlir][sparse] Refine f695554a2a55 wording a bit and fix the double conversion I broke with aggressive copy&paste

(cherry picked from commit 726719e970abb6d6fe014ed96f5ca838807dd840)

[mlir][sparse] Use the correct ABI on x86 and re-enable tests

c7ec6e19d5446a448f888b33f66316cf2ec6ecae made LLVM adhere to the x86
psABI and pass bf16 in SSE registers instead of GPRs. This breaks the
custom versions of runtime functions we have for bf16 conversion. A
great fix for this would be to use __bf16 types instead which carry the
right ABI, but that type isn't widely available.

Instead just pretend it's a 32 bit float on the ABI boundary and
carefully cast it to the right type.

Fixes #57042

(cherry picked from commit f695554a2a5550ae40da35af9ac22bfcca5db09a)

[mlir][sparse][bf16] disable two bf16 tests

Supposedly our ABI issues were fixed, per issue:
https://github.com/llvm/llvm-project/issues/55992

However, with a recent changes to bf16, these tests
fail again; not sure why yet:
https://reviews.llvm.org/D130832
https://lab.llvm.org/buildbot/#/builders/61/builds/30600

So we disable the tests for now. Issue is tracked in:
https://github.com/llvm/llvm-project/issues/57042

Differential Revision: https://reviews.llvm.org/D131621

(cherry picked from commit 6b7459115f7b1c43f81ad8dfb5da9d206d3b1e06)

[compiler-rt][BF16] Provide __truncdfbf2 and __truncsfbf2 only when __bf16 is available

Differential Revision: https://reviews.llvm.org/D131147

(cherry picked from commit f061cfb31730b72b7d8920bb4a306a1d2ce7f2e4)

[X86][BF16] Enable __bf16 for x86 targets.

X86 psABI has updated to support __bf16 type, the ABI of which is the
same as FP16. See https://discourse.llvm.org/t/patch-add-optional-bfloat16-support/63149

Reviewed By: pengfei

Differential Revision: https://reviews.llvm.org/D130964

(cherry picked from commit e4888a37d36780872d685c68ef8b26b2e14d6d39)

[X86][BF16] Make backend type bf16 to follow the psABI

X86 psABI has updated to support __bf16 type, the ABI of which is the
same as FP16. See https://discourse.llvm.org/t/patch-add-optional-bfloat16-support/63149

This is an alternative of D129858, which has less code modification and
supports the vector type as well.

Reviewed By: LuoYuanke

Differential Revision: https://reviews.llvm.org/D130832

(cherry picked from commit c7ec6e19d5446a448f888b33f66316cf2ec6ecae)

[LLD] [COFF] Add support for a new, mingw specific embedded directive -exclude-symbols:

This is an entirely new embedded directive - extending the GNU ld
command line option --exclude-symbols to be usable in embedded
directives too.

(GNU ld.bfd also got support for the same new directive, currently in
the latest git version, after the 2.39 branch.)

This works as an inverse to the regular embedded dllexport directives,
for cases when autoexport of all eligible symbols is performed.

Differential Revision: https://reviews.llvm.org/D130120

(cherry picked from commit 5d513ef6cf4646e64bbb1d5f8610afd530964588)

[COFF] Change a llvm::StringSet<> to llvm::DenseSet<StringRef>. NFC

The former stores strings and is therefore more expensive.

(cherry picked from commit dfe2a3f3eb92b6a94453a74f3f0a4552f6965fcc)

[LLD] [MinGW] Implement the --exclude-symbols option

This adds support for the existing GNU ld command line option, which
allows excluding individual symbols from autoexport (when linking a
DLL and no symbols are marked explicitly as dllexported).

Differential Revision: https://reviews.llvm.org/D130118

(cherry picked from commit d1da6469f9ea9b078276ee2e098241f0440468be)

[libcxx] [test] Merge the experimental-lib-exports testcases into static-lib-exports

Since bb939931a1adb9a47a2de13c359d6a72aeb277c8, the c++experimental
library is always built, so these tested files should always be built
(even if they aren't used in tests).

Differential Revision: https://reviews.llvm.org/D129399

(cherry picked from commit b8717d19cfd49bfdbd462ea42cd94b94959e4feb)

[libc++] Add missing includes of <cstddef>

(cherry picked from commit b1009bbd9e3d5acd85e92cb7f9a1109d2e72967c)

[libc++] Make __libcpp_verbose_abort [[noreturn]]

This will allow using it in functions that are [[noreturn]] themselves.

Differential Revision: https://reviews.llvm.org/D131408

(cherry picked from commit f5738c51452f90d7f33963d1c0c6f8e7f3d801e3)

[libc++][ranges] Sets ranges feature-test macro.

D131234 marked the ranges papers as complete, but it didn't set the
feature-test macro.

Reviewed By: ldionne, var-const, #libc

Differential Revision: https://reviews.llvm.org/D131326

(cherry picked from commit 195287d90afb1b97a0fb869da501370e7c3e67c6)

[libc++][NFC] Fix signature of main in test

(cherry picked from commit 27442728cd2e28bfaf0f2d89ad6378b4377e9c66)

[libc++] Add missing <stdbool.h> to the modulemap

It used to be defined by the compiler, but libc++ now provides it.

Differential Revision: https://reviews.llvm.org/D131201

(cherry picked from commit 0a5c344a84a452452185f3a6bd7d7679a42abb42)

Change prototype merging error into a warning for builtins

As was observed in https://reviews.llvm.org/D123627#3707635, it's
confusing that a user can write:
```
float rintf(void) {}
```
and get a warning, but writing:
```
float rintf() {}
```
gives an error. This patch changes the behavior so that both are
warnings, so that users who have functions which conflict with a
builtin identifier can still use that identifier as they wish.

Differential Revision: https://reviews.llvm.org/D131499

(cherry picked from commit 4c02ab8c9742f6c32b17f49a306b3b072486f5c5)

[AArch64][LoopVectorize] Introduce trip count minimal value threshold to ignore tail-folding.

After D121595 was commited, I noticed regressions assosicated with small trip
count numbersvectorisation by tail folding with scalable vectors. As a solution
for those issues I propose to introduce the minimal trip count threshold value.

  Differential Revision: https://reviews.llvm.org/D130755

(cherry picked from commit cab6cd68340255be241b7cf169c67a1899ced115)

[clang] Require strict matches for defines for PCH in GCC style directories

When clang includes a PCH, it tolerates some amount of differences
between the defines used when creating and when including the PCH
- this seems to be intentionally allowed in
c379c072405f39bca1d3552408fc0427328e8b6d (and later extended in
b63687519610a73dd565be1fec28332211b4df5b).

When using a PCH (or when picking a PCH out of a directory containing
multiple candidates) Clang used to accept the header if there were
defines on the command line when creating the PCH that are missing
when using the PCH, or vice versa, defines only set when using the
PCH.

The only cases where Clang explicitly rejected the use of a PCH
is if there was an explicit conflict between the options, e.g.
-DFOO=1 vs -DFOO=2, or -DFOO vs -UFOO.

The latter commit added a FIXME that we really should check whether
mismatched defines actually were used somewhere in the PCH, so that
the define would affect the outcome. This FIXME has stood unaddressed
since 2012.

This differs from GCC, which rejects PCH files if the defines differ
at all.

When explicitly including a single PCH file, the relaxed policy
of allowing minor differences is harmless for correct use cases
(but may fail to diagnose mismtaches), and potentially allow using
PCHs in wider cases (where the user intentionally know that the
differences in defines are harmless for the PCH).

However, for GCC style PCH directories, with a directory containing
multiple PCH variants and the compiler should pick the correct match
out of them, Clang's relaxed logic was problematic. The directory
could contain two otherwise identical PCHs, but one built with -DFOO
and one without. When attempting to include a PCH and iterating over
the candidates in the directory, Clang would essentially pick the
first one out of the two, even if there existed a better, exact
match in the directory.

Keep the relaxed checking when specificlly including one named
PCH file, but require strict matches when trying to pick the right
candidate out of a GCC style directory with alternatives.

This fixes https://github.com/lhmouse/mcfgthread/issues/63.

Differential Revision: https://reviews.llvm.org/D126676

(cherry picked from commit c843c921a1a385bb805b2338d980436c94f83f19)

[RelLookupTableConverter] Bail on invalid pointer size (x32)

The RelLookupTableConverter pass currently only supports 64-bit
pointers.  This is currently enforced using an isArch64Bit() check
on the target triple. However, we consider x32 to be a 64-bit target,
even though the pointers are 32-bit. (And independently of that
specific example, there may be address spaces with different pointer
sizes.)

As such, add an additional guard for the size of the pointers that
are actually part of the lookup table.

Differential Revision: https://reviews.llvm.org/D131399

(cherry picked from commit 4ac00789e1b30145ec3cacc4b2a66cb755ff9e4a)

[Attributor][FIX] Visit same instructions with different scopes

If we collect potential values we need to visit a value even if we have
seen it before if the scope is different. The scope is part of the
result after all. Test included.

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

Differential Revision: https://reviews.llvm.org/D131597

(cherry picked from commit b65471d7152d15790ae599326da86b7e6cfb4580)

[Libomptarget][CUDA] Check CUDA compatibilty correctly

We recently added support for multi-architecture binaries in
libomptarget. This is done by extracting the architecture from the
embedded image and comparing it with the major and minor version
supported by the current CUDA installation. Previously we just compared
these directly, which was not correct for binary compatibility. The CUDA
documentation states that we can consider any image with an equivalent
major or a greater or equal to minor compatible with the current image.
Change the check to use this new logic in the CUDA plugin.

Fixes #57049

Reviewed By: jdoerfert, ye-luo

Differential Revision: https://reviews.llvm.org/D131567

(cherry picked from commit fdbb15355e7977b914cbd7e753b5e909d735ad83)

[clang] add APValue type check in `TryPrintAsStringLiteral`

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

https://reviews.llvm.org/D115031 improved printing of non-type template
parameter args. But checking if the end of Inits is 0 without checking
if APValue is an integer, causes clang to segfault. This patch adds
the code to check the type. (May not be a proper bugfix.)

Reviewed By: aaron.ballman, lichray

Differential Revision: https://reviews.llvm.org/D131466

(cherry picked from commit 55d3b79d159bab53b140860279486db8a1c0e4f3)

[RISCVInsertVSETVLI] Remove an unsound optimization

This fixes a bug reported privately by @craig.topper. Here's an example which illustrates the problem:

vsetivli a1, a0, e32, m1, ta, mu # both DefInfo and PrevInfo
vsetivli a2, a1, e32, m4, ta, mu

With the unsound result being:

vsetivli a1, a0, e32, m1, ta, mu
vsetivli a2, a0, e32, m4, ta, mu

Consider the case where this is running on a machine with VLEN=512,. For this case, the VLMAXs are 16 and 64 respectively.

Consider for a0 = 33. The correct result is: a1 = 16, and a2 = 16

After the unsound optimization: a1 = 16 and a2 = 33

This particular example used VLMAXs which differed by more than a power of two. With a difference of only one power of two, there's another form of this bug which involves the AVL < 2 x VLMAX special case, but that ones more complicated to construct as many examples turn out accidentally sound.

This patch takes the approach of simply removing the unsound optimization, but there are multiple sound sub-cases of it. I plan to return to at least a couple of them, but figured it was cleaner to remove the unsound optimization (for ease of backporting), and then review the new optimizations on their own.

Differential Revision: https://reviews.llvm.org/D131264

(cherry picked from commit 9a9848f4b95895ad97d3dc117f0a94773dc1607f)

Revert "[clang] Pass FoundDecl to DeclRefExpr creator for operator overloads"

This reverts commit 4e94f6653150511de434fa7e29b684ae7f0e52b6.
See https://reviews.llvm.org/D129973#3698969 for reasoning.

(cherry picked from commit df48e3fbcc8be1f4c04bd97517d12e662f54de75)

[llvm-ranlib] Support more than one input file

BSD and GNU ranlib support more than one input file. Implement this.

While here, update OVERVIEW (Ranlib => ranlib) since "ranlib" is more common.
Remove "speed access" since the index has nothing to do with performance: it is
mandatory for GNU ld and gold but ignored for ld.lld (D119074).

Close https://github.com/llvm/llvm-project/issues/54565

Differential Revision: https://reviews.llvm.org/D131375

(cherry picked from commit aa173573198e024b065c5f6523ce26bb865781b7)

[llvm-ar] Remove unused parameter. NFC

(cherry picked from commit 350f17ab52ec9df60095f7b7bccd49c429885ef7)

[libc++][format] Exposes basic-format-string

This paper was accepted during the last plenary and is intended to be
backported to LLVM 15. When backporting the release notes in the branch
should be updated too.

Note the feature-test macro isn't updated since this will change; three
papers have updated the same macro in the same plenary.

Implements:
- P2508R1 Exposing std::basic-format-string

Reviewed By: ldionne, #libc

Differential Revision: https://reviews.llvm.org/D130643

(cherry picked from commit f712775dafdb221fdf73f38819fa9e618aec6b67)

[flang][test] Don't require .exe suffix.

The suffix is only added then the path the (lld-)link.exe is fully
resolved. Otherwise it may stay "link" or "lld-link".

On non-Windows platforms, lld-link also exists as a symbolic link to
lld, such that the full the path to lld-link might also be resolved
without .exe suffix in this case.

Note that CLANG_DEFAULT_LINKER could be set to other linkers such as
mold, in which case the test may still fail. This also applies to the
non-Windows tests that require "ld" in the linker name.

Fixes issue #56955

(cherry picked from commit 8c0979c8f7723306862b33583c6bdb1f4566a969)

[clangd] Add release notes

[DAG] Ensure Legal BUILD_VECTOR elements types in shuffle->And combine

D129150 added a combine from shuffles to And that creates a BUILD_VECTOR
of constant elements. We need to ensure that the elements are of a legal
type, to prevent asserts during lowering.

Fixes #56970.

Differential Revision: https://reviews.llvm.org/D131350

(cherry picked from commit 061e0189a3dab6b1831a80d489ff1b15ad93aafb)

[ARM] Regenerate vector_store.ll tests. NFC

(cherry picked from commit f8d976171f2a1b7bf9268929f77904973edb0378)

[scudo] Try to fix standalone build on armv7

When linking scudo standalone on armv7, it can't find symbols related to
unwinding (e.g. __aeabi_unwind_cpp_pr0). This is because it is passing
--unwindlib=none. This patch hacks around the issue by adding
COMPILER_RT_UNWINDER_LINK_LIBS to the link line.

I don't know anything about scudo, so I'm not sure what the original
intention was.

See also https://github.com/llvm/llvm-project/issues/56900

Differential Revision: https://reviews.llvm.org/D131250

(cherry picked from commit 8342ea6eac85bd20c56be0ab71b4ebbccd134c67)

[SPIR-V] Disable opaque pointers in relese 15

As discussed on RFC mapping into SPIR-V requires pointer being preserved in some cases: https://discourse.llvm.org/t/rfc-better-support-for-typed-pointers-in-an-opaque-pointer-world/63339/23?u=anastasiastulova

As the work is still unfinished the best approach is to continue using pointer types.

Note that this change is only planned to be committed in release 15 branch.

This fixing PR56660.

Reviewed By: jcranmer-intel

Differential Revision: https://reviews.llvm.org/D130766

[ELF] Support --package-metadata

This was recently introduced in GNU linkers and it makes sense for
ld.lld to have the same support. This implementation omits checking if
the input string is valid json to reduce size bloat.

Differential Revision: https://reviews.llvm.org/D131439

(cherry picked from commit dbd04b853b680b0a383e5f58edf3643364f67bdf)

[OpenMP] Only include CMAKE_DL_LIBS on unix platforms

CMAKE_DL_LIBS is documented as "Name of library containing dlopen
and dlclose".

On Windows platforms, there's no system provided dlopen/dlclose, but
it can be argued that if you really intend to call dlopen/dlclose,
you're going to be using a third party compat library like
https://github.com/dlfcn-win32/dlfcn-win32, and CMAKE_DL_LIBS should
expand to its name.

This has been argued upstream in CMake in
https://gitlab.kitware.com/cmake/cmake/-/issues/17600 and
https://gitlab.kitware.com/cmake/cmake/-/merge_requests/1642, that
CMAKE_DL_LIBS should expand to "dl" on mingw platforms.

The merge request wasn't merged though, as it caused some amount of
breakage, but in practice, Fedora still carries a custom CMake patch
with the same effect.

Thus, this patch fixes cross compiling OpenMP for mingw targets
on Fedora with their custom-patched CMake.

Differential Revision: https://reviews.llvm.org/D130892

(cherry picked from commit 7f24fd26a8abaef2fa4561aa399adde81d9c563a)

[OpenMP][libomp] Detect if test compiler has omp.h

omp50_taskdep_depobj.c relies on the test compiler's omp.h file.
If the test compiler does not have an omp.h file, then use the one
within the build tree.

Fixes: https://github.com/llvm/llvm-project/issues/56820
Differential Revision: https://reviews.llvm.org/D131000

(cherry picked from commit 9cf6511bff97007401238f6cff6bf80cb9af04a5)

[DAGCombiner] Extend visitAND to include EXTRACT_SUBVECTOR

Eliminate an AND by redefining an anyext|sext|zext.

     (and (extract_subvector (anyext|sext|zext v) _) iN_mask)
  => (extract_subvector (zeroext_iN v))

Differential Revision: https://reviews.llvm.org/D130782

(cherry picked from commit 41119a0f520d07a438f7434f17ce63cc3a942d1b)

[AArch64][DAGCombine] Add performBuildVectorCombine 'extract_elt ~> anyext'

A build vector of two extracted elements is equivalent to an extract
subvector where the inner vector is any-extended to the
extract_vector_elt VT, because extract_vector_elt has the effect of an
any-extend.

  (build_vector (extract_elt_i16_to_i32 vec Idx+0) (extract_elt_i16_to_i32 vec Idx+1))
  => (extract_subvector (anyext_i16_to_i32 vec) Idx)

Depends on D130697

Differential Revision: https://reviews.llvm.org/D130698

(cherry picked from commit 487fa6f8c3af87232f7ff9484568be7782f7f8b2)

[NFC][AArch64] Precommit vector-fcvt tests

Add tests which show code quality of uitofp and sitofp.

Differential Revision: https://reviews.llvm.org/D130697

(cherry picked from commit 6953e754c7a887b22c56ce7b0526506e4aa86e7f)

[OpenMP] Fix warnings about unused expressions when OMPT_LOOP_DISPATCH is a no-op. NFC.

This fixes warnings like these:

../runtime/src/kmp_dispatch.cpp:2159:24: warning: left operand of comma operator has no effect [-Wunused-value]
    OMPT_LOOP_DISPATCH(*p_lb, *p_ub, pr->u.p.st, status);
                       ^~~~~
../runtime/src/kmp_dispatch.cpp:2159:31: warning: left operand of comma operator has no effect [-Wunused-value]
    OMPT_LOOP_DISPATCH(*p_lb, *p_ub, pr->u.p.st, status);
                              ^~~~~
../runtime/src/kmp_dispatch.cpp:2159:46: warning: left operand of comma operator has no effect [-Wunused-value]
    OMPT_LOOP_DISPATCH(*p_lb, *p_ub, pr->u.p.st, status);
                                     ~~~~~~~ ^~
../runtime/src/kmp_dispatch.cpp:2159:50: warning: expression result unused [-Wunused-value]
    OMPT_LOOP_DISPATCH(*p_lb, *p_ub, pr->u.p.st, status);
                                                 ^~~~~~

(cherry picked from commit 3f25ad335b4ef882cd4e336f9d9ac1606220f572)

[CodeGen] Fixed undeclared MISchedCutoff in case of NDEBUG and LLVM_ENABLE_ABI_BREAKING_CHECKS

This patch fixes the error llvm/lib/CodeGen/MachineScheduler.cpp(755): error C2065: 'MISchedCutoff': undeclared identifier in case of NDEBUG and LLVM_ENABLE_ABI_BREAKING_CHECKS.
Note MISchedCutoff is declared under #ifndef NDEBUG.

Reviewed By: RKSimon

Differential Revision: https://reviews.llvm.org/D130425

(cherry picked from commit adc387460d85a371d111bcd3e08fdc8d4f26ddd5)

Wrap `llvm_unreachable` macro in do-while loop

Macros that expand into multiple terms can cause interesting preprocessor hickups depending
on the context they are used in. https://github.com/llvm/llvm-project/issues/56867 reported
a miscompilation of `llvm_unreachable(msg)` inside a `LLVM_DEBUG({ ... })` block. We were
able to fix it by wrapping the expansion in a `do {} while(false)`.

Differential Revision: https://reviews.llvm.org/D131337

(cherry picked from commit 7a66fe1075cfc7568554aeea9c40997dfb581979)

[lld-macho] Support EH frame pointer encodings that use sdata4

Previously we only supporting using the system pointer size (aka the
`absptr` encoding) because `llvm-mc`'s CFI directives always generate EH
frames with that encoding. But libffi uses 4-byte-encoded, hand-rolled
EH frames, so this patch adds support for it.

Fixes #56576.

Reviewed By: #lld-macho, oontvoo

Differential Revision: https://reviews.llvm.org/D130804

(cherry picked from commit 6c9f6812523a706c11a12e6cb4119b0cf67bbb21)

[libc++] Allow enabling assertions when back-deploying

When back-deploying to older platforms, we can still provide assertions,
but we might not be able to provide a great implementation for the verbose
handler. Instead, we can just call ::abort().

Differential Revision: https://reviews.llvm.org/D131199

(cherry picked from commit e36f9e13bca41223bd6af7e49bf020e58a676e9d)

[libc++][ranges][NFC] Mark the completed Ranges papers and issues as done.

The newly-completed papers:
- P0896R4 ("The One Ranges Proposal");
- P1243R4 ("Rangify New Algorithms");
- P1252R2 ("Ranges Design Cleanup");
- P1716R3 ("Range Comparison Algorithms Are Over-Constrained");
- P1871R1 ("Concept traits should be named after concepts");
- P2106R0 ("Alternative wording for GB315 and GB316").

Differential Revision: https://reviews.llvm.org/D131234

(cherry picked from commit 3fa291fa925dad4bae215fbcbc64db5ce66f0d9f)

[libc++][ranges][NFC] Make sure all implemented algorithms are enabled in "robust" tests.

Also fix `std::find_first_of` (which accidentally copied the predicate
in the implementation).

Differential Revision: https://reviews.llvm.org/D131235

(cherry picked from commit 8ac015caf627a0db89540950d6343e955ba9500b)

[libc++] Clarify comment in CI pipeline definition

This partially reverts commit 7d855bb8e133. The comments were actually
not outdated, they were simply unclear.

(cherry picked from commit cf08452e918e04c5a95b6dce11a977b317ac4476)

[libc++][NFC] Remove outdated comment in CI pipeline definition

(cherry picked from commit 7d855bb8e133720ac1555dc189d9f41e7a50ea93)

[libc++] Fix a hard error in `contiguous_iterator<NoOperatorArrowIter>`.

Evaluating `contiguous_iterator` on an iterator that satisfies all the
constraints except the `to_address` constraint and doesn't have
`operator->` defined results in a hard error. This is because
instantiating `to_address` ends up instantiating templates
dependent on the given type which might lead to a hard error even
in a SFINAE context.

Differential Revision: https://reviews.llvm.org/D130835

(cherry picked from commit 52d4c5016c4f8eca6abe84f658fc5f358bdfd2d0)

[libc++][ranges] Implement `ranges::is_permutation`

Co-authored-by: Konstantin Varlamov <varconst@apple.com>
Differential Revision: https://reviews.llvm.org/D127194

(cherry picked from commit 4038c859e58c12e997041927a87e880f2f3ef883)

[libc++][NFC] Remove rebase artifact

I found it in this commit: https://github.com/llvm/llvm-project/commit/a203acb9dd7227323d6161431225189d49917744

Reviewed By: Mordante

Differential Revision: https://reviews.llvm.org/D131163

(cherry picked from commit 1915c1c01e6c84a1fda5a313f85e2a3dbccd7ce0)

[libc++][ranges] Implement `ranges::clamp`

Differential Revision: https://reviews.llvm.org/D126193

(cherry picked from commit a203acb9dd7227323d6161431225189d49917744)

[libc++][ranges] Implement `ranges::rotate`.

Also fix `ranges::stable_sort` and `ranges::inplace_merge` to support
proxy iterators now that their internal implementations can correctly
dispatch `rotate`.

Differential Revision: https://reviews.llvm.org/D130758

(cherry picked from commit 36c746ca2d5b325a7ac64135c1ff8774c06ab34c)

[libc++] Mark -fexperimental-library test as unsupported on another AppleClang

(cherry picked from commit 144cea2ce9b9536acaf2a7513b9fdccfd3880db9)

[LLD][COFF] Ignore DEBUG_S_XFGHASH_TYPE/VIRTUAL

These are new debug types that ships with the latest
Windows SDK and would warn and finally fail lld-link.

The symbols seems to be related to Microsoft's XFG
which is their version of CFG. We can't handle any of
this yet, so for now we can just ignore these types
so that lld doesn't fail with a new version of Windows
SDK.

Fixes: #56285
Reviewed By: rnk

Differential Revision: https://reviews.llvm.org/D129378

(cherry picked from commit 576375a2d670a7b1bd84b53b0187605a5f4ea0c8)

Revert "[compiler-rt][CMake] Enable TF intrinsics on powerpc32 Linux"

As mentioned in https://reviews.llvm.org/D121379#3690593, this
change broke the build of compiler-rt targeting powerpc using GCC.
The 32-bit powerpc target is not supposed to emit 128-bit libcalls
-- if it does, then that's a backend bug and needs to be fixed there.

This reverts commit 8f24a56a3a9363f353c8da318d97491a6818781d.

Differential Revision: https://reviews.llvm.org/D130988

(cherry picked from commit 542977d43841820614a32823c33415042430e230)

[ELF][AArch64] Fix potentially corrupted section content for PAC

D74537 introduced a bug: if `(config->andFeatures & GNU_PROPERTY_AARCH64_FEATURE_1_PAC) != 0`
with -z pac-plt unspecified, we incorrectly use AArch64BtiPac, whose writePlt will make
out-of-bounds write after the .plt section. This is often benign because the
output section after .plt will usually overwrite the content.

This is very difficult to test without D131247 (Parallelize writes of different OutputSections).

(cherry picked from commit d7cbfcf36ace575ec90434624279dd3ebce78c47)

[ELF] Keep only getTarget() call. NFC

The place from D61712 seems unneeded now. We can just use the place added by
D62609 (support AArch64 BTI/PAC).

(cherry picked from commit e89d6d2ac527f973c43563373dfdeb9e4c3bbcc5)

[ELF][PPC64] Fix potentially corrupted section content with empty .got

D91426 makes .got possibly empty while needed. If .got and .data have the same
address, and .got's content is written after .data, the first word of .data will
be corrupted.

The bug is not testable without D131247.

(cherry picked from commit 28d05d672300e51f53c73fe9a4bd053e73844247)