packaging: remove -gdwarf-* on llvm_release_build

Fix error: dwarf-4: linker input file not found: No such file or directory

Change-Id: If0c5e0f282aac61e4ba1b377d667ddea7f5ab885
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>

BuildIgnore build-compare

Change-Id: I2765375e74689947392c06a4d96a27ff458a26c0
Signed-off-by: Hyunggi Lee <hyunggi.lee@samsung.com>

Link libclang_rt.asan.so against libatomic when necessary

To build libclang_rt.asan.so on RISC-V it is required to link it against
libatomic.

Change-Id: Iafdc20fc8ecffeeaa289e03b01267bbabdd48a9e
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>

Revert "Revert "[sanitizer_common] Use atomic builtin in sanitizer_atomic_clang.h""

This reverts commit 6b19188ca7ff28a9c0f654d36572bc716c189a8f.

Commit 6b19188ca7ff28a9c0f654d36572bc716c189a8f is unnecessary if
libclang_rt.asan.so is linked against libatomic.

Change-Id: I01d9ceac32ae360f395f3e888d65bd07ec24e6cf
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>

Revert "[sanitizer_common] Use atomic builtin in sanitizer_atomic_clang.h"

To fix link issue on riscv64:
undefined reference to `__atomic_compare_exchange_1'

This reverts commit 067650fd12fccf44de1d7c148b50658831c672b0.

Change-Id: I19d557c9ffb34f5bdacbd14e457ddbfd53aadbb6

[packaging] build llvm for riscv64

Don't build LLDB. It doesn't support RISC-V yet.

Change-Id: I069101727569d9bddda1205bc5775912d30a632c
Signed-off-by: Łukasz Stelmach <l.stelmach@samsung.com>

packaging: Bump version to 15.0.7

Change-Id: I14c24a8d27c0c85107eb77d20070162744f6433a
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>

[packaging] Always build with non-asan for all architecture

Always build with non-asan not only i586 but also all other
architectures. Otherwise, llvm build will be failed from below:
  /home/abuild/rpmbuild/BUILD/llvm-10.0.0/compiler-rt/lib/asan/asan_internal.h:24:3: error: #error "The AddressSanitizer run-time should not be"
     24 | # error "The AddressSanitizer run-time should not be"
     25 |         " instrumented by AddressSanitizer"

Change-Id: I3189246d5c6ed63760b7c2699dcfd830c5b4bce6
Signed-off-by: Seung-Woo Kim <sw0312.kim@samsung.com>

[Tizen] Change libsosplugin.so path

Change-Id: I9d232965b69757cceb37afe19273c28d8cb6e7f7

Revert "[packaging] Enable llvm build with clang"

This reverts commit d86a9ce77e32574dee8eb4048fd95fd744eedcdf.

Change-Id: I87f2237d09e2e1e6fd18efb0b28dcd0beb057dcd

Fix build error for `Add search paths for libstdc++`

Change-Id: I2ac8cb6da767219d75166b4a03fc91200a96e538
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>

[packaging] Enable llvm build with clang

Change-Id: I6fcc807ad7aafec3d4ec055ab48bdfc3fb3cd41e
Signed-off-by: Slava Barinov <v.barinov@samsung.com>
Signed-off-by: Dongkyun Son <dongkyun.s@samsung.com>

[packaging] Create clang-gcc-replace package

The package provides symlinks %_bindir/gcc and %_bindir/g++ for clang and
clang++ respectively.

Can be used for compiler enforcement in environments which do not allow
compiler change.

Change-Id: I49660b9a705162cebe569a8b3df0714f472d86ad
Signed-off-by: Slava Barinov <v.barinov@samsung.com>

[packaging] Enable build in Clang environment

Enforce fpu=neon for armv7l and armv7hl builds
Enable libstdc++ install paths for all platforms
Switch compilers to %__cc and %__cxx

Change-Id: Ie0f55dc36d11df398b5b397951c2b40d751506c3
Signed-off-by: Slava Barinov <v.barinov@samsung.com>

[llvm][clang]  Add support for Tizen toolchain vendor

Port of
ebf1682d714e4b6c1487ea0e136cf7c1ec30f46d
8845ba7f79513b7e362fed80bb57b708352ddbbd

Change-Id: I5f2261b5ab6850c3592fc26f159b978410ac5e0e
Signed-off-by: Slava Barinov <v.barinov@samsung.com>

[packaging] Add packaging

Change-Id: Ia0f97e3b5d3901fe5183e51faad7b01bd3af6cd8
Signed-off-by: Slava Barinov <v.barinov@samsung.com>

[libc++] Fix memory leaks when throwing inside std::vector constructors

Fixes #58392

Reviewed By: ldionne, #libc

Spies: alexfh, hans, joanahalili, dblaikie, libcxx-commits

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

libc++: bring back the unsigned in the return type in wcstoull_l

got remove here:
https://github.com/llvm/llvm-project/commit/67b0b02ec9f2bbc57bf8f0550828d97f460ac11f#diff-e41832b8aa26da45585a57c5111531f2e1d07e91a67c4f8bf1cd6d566ae45a2bR42

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

(cherry picked from commit fc87452916c0d8759625aad65e9335778ce9cc68)

[RegAllocFast] Handle new debug values for spills

These new debug values get inserted after the place where the spill
happens, which means they won't be reached by the reverse traversal of
basic block instructions. This would crash or fail assertions if they
contained any virtual registers to be replaced. We can manually handle
the new debug values right away to resolve this.

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

Reviewed By: StephenTozer

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

(cherry picked from commit 87f57f459e7acbb00a6ca4ee6dec6014c5a97e07)

[wasm-ld] Define a `__heap_end` symbol marking the end of allocated memory.

Define a `__heap_end` symbol that marks the end of the memory region
that starts at `__heap_base`. This will allow malloc implementations to
know how much memory they can use at `__heap_base` even if someone has
done a `memory.grow` before they can initialize their state.

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

[TypePromotion] Add truncate in ConvertTruncs when the original truncate type is not extend type

If the src type is not extend type, after convert the truncate to and we need to truncate the and also to make sure the all user is legal.

The old fix D137613 doesn't work when the truncate convert to and have the other users. So this time I try to add the truncate after and to avoid all these potential issues.

Fix: #59554

Reviewed By: samparker

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

(cherry picked from commit a0b470c9848c638e86f97eca53063642e07cea67)

[X86] Don't zero out %eax if both %al and %ah are used

The iterator over super and sub registers doesn't include both 8-bit
registers in its list. So if both registers are used and only one of
them is live on return, then we need to make sure that the other 8-bit
register is also marked as live and not zeroed out.

Reviewed By: nickdesaulniers

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

(cherry picked from commit 14d4cddc5506fb0fd3c4ac556b4edd970aa151eb)

Bump version to 15.0.7

[CodeGen][ARM] Fix ARMABIInfo::EmitVAAarg crash with empty record type variadic arg

Fix ARMABIInfo::EmitVAAarg crash with empty record type variadic arg

Open issue: https://github.com/llvm/llvm-project/issues/58794

Reviewed By: rjmccall

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

(cherry picked from commit 80f444646c62ccc8b2399d60ac91e62e6e576da6)

[ELF] Handle GCC collect2 -plugin-opt= on Windows

Follows up on commit cd5d5ce235081005173566c99c592550021de058 by
additionally ignoring relative paths ending in "lto-wrapper.exe" as
can be the case for GCC cross-compiled for Windows.

Reviewed By: tejohnson

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

(cherry picked from commit cf4f35b78871aecc21e663067c57e60595bd7197)

Revert "Reapply: Add an error message to the default SIGPIPE handler"

This patch is spamming compiles with unhelpful and confusing messages.
E.g. the Linux kernel uses "grep -q" in several places. It's meant to
quit with a return code of zero when the first match is found. This can
cause a SIGPIPE signal, but that's expected, and there's no way to turn
this error message off to avoid spurious error messages.

UNIX03 apparently doesn't require printing an error message on SIGPIPE,
but specifically when there's an error on the stdout stream in a normal
program flow, e.g. when SIGPIPE trap is disabled.

A separate patch is planned to address the specific case we care most
about (involving llvm-nm).

This reverts commit b89bcefa6202e310eb3167dd1c37f1807377ec8d.

Link: https://github.com/llvm/llvm-project/issues/59037
Link: https://github.com/ClangBuiltLinux/linux/issues/1651
Differential Revision: https://reviews.llvm.org/D138244

(cherry picked from commit 4787efa38066adb51e2c049499d25b3610c0877b)

Bump version to 15.0.6

Bump version to 15.0.5

[VectorUtils] Skip interleave members with diff type and alloca sizes.

Currently, codegen doesn't support cases where the type size doesn't
match the alloc size. Skip them for now.

Fixes #58722.

(cherry picked from commit 758699c39984296f20a4dac44c6892065601c4cd)

[lldb] Get rid of __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS

C++11 made the use of these macro obsolete, see https://sourceware.org/bugzilla/show_bug.cgi?id=15366

As a side effect this prevents https://github.com/swig/swig/issues/2193.

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

(cherry picked from commit 81fc5f7909a4ef5a8d4b5da2a10f77f7cb01ba63)

[lldb] Fix 'error: non-const lvalue...' caused by SWIG 4.1.0

Fix the failure caused by change in SwigValueWraper for C++11 and later
for improved move semantics in SWIG commit.

https://github.com/swig/swig/commit/d1055f4b3d51cb8060893f8036846ac743302dab
(cherry picked from commit f0a25fe0b746f56295d5c02116ba28d2f965c175)

[GlobalOpt] Don't remove inalloca from varargs functions

Varargs and inalloca have a weird interaction where varargs are actually
passed via the inalloca alloca. Removing inalloca breaks the varargs
because they're still not passed as separate arguments.

Fixes #58718

Reviewed By: rnk

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

(cherry picked from commit 8c49b01a1ee051ab2c09be4cffc83656ccc0fbe6)

[analyzer] Workaround crash on encountering Class non-type template parameters

The Clang Static Analyzer will crash on this code:
```lang=C++
struct Box {
  int value;
};
template <Box V> int get() {
  return V.value;
}
template int get<Box{-1}>();
```
https://godbolt.org/z/5Yb1sMMMb

The problem is that we don't account for encountering `TemplateParamObjectDecl`s
within the `DeclRefExpr` handler in the `ExprEngine`.

IMO we should create a new memregion for representing such template
param objects, to model their language semantics.
Such as:
 - it should have global static storage
 - for two identical values, their addresses should be identical as well
http://eel.is/c%2B%2Bdraft/temp.param#8

I was thinking of introducing a `TemplateParamObjectRegion` under `DeclRegion`
for this purpose. It could have `TemplateParamObjectDecl` as a field.

The `TemplateParamObjectDecl::getValue()` returns `APValue`, which might
represent multiple levels of structures, unions and other goodies -
making the transformation from `APValue` to `SVal` a bit complicated.

That being said, for now, I think having `Unknowns` for such cases is
definitely an improvement to crashing, hence I'm proposing this patch.

Reviewed By: xazax.hun

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

(cherry picked from commit b062ee7dc4515b0a42157717105839627d5542bb)

Link libclangBasic against libatomic when necessary.

This is necessary at least on PPC32.

Depends on D136280.

Bug: https://bugs.gentoo.org/874024
Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Tested-by: erhard_f@mailbox.org <erhard_f@mailbox.org>
Differential Revision: https://reviews.llvm.org/D136282

(cherry picked from commit 20132d8eaa68a6c53e152718beda1dc0f4c9ff6c)

Link liblldCOFF against libatomic when necessary

Also simplify code for liblldCommon using the new LLVM_ATOMIC_LIB variable.

Depends on D136280.

Bug: https://bugs.gentoo.org/832675
Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Tested-by: erhard_f@mailbox.org <erhard_f@mailbox.org>
Differential Revision: https://reviews.llvm.org/D136281

(cherry picked from commit f0b451c77f14947e3e7d314f048679fa2f5c6298)

Set LLVM_ATOMIC_LIB variable for convenient linking against libatomic

* Set LLVM_ATOMIC_LIB to keep track of when we need to link against libatomic.
* Add detection of mold linker which is required for this.
* Use --as-needed when linking against libatomic as a bonus. On some platforms,
  libatomic may be required only sometimes.

Bug: https://bugs.gentoo.org/832675
Thanks-to: Arfrever Frehtes Taifersar Arahesis <Arfrever@Apache.Org>
Tested-by: erhard_f@mailbox.org <erhard_f@mailbox.org>
Differential Revision: https://reviews.llvm.org/D136280

(cherry picked from commit fa981b541365190ae646d2dce575706cd0626cf7)

[TypePromotion] Replace Zext to Truncate for the case src bitwidth is larger

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

Reviewed By: samtebbs

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

(cherry picked from commit 597f44409236bf7fa933a4ce18af23772e28fb43)

[cmake] Add missing CMakePushCheckState include to FindLibEdit.cmake

Add the missing include to fix an error when `cmake_push_check_state()`
is called and incidentally the CMakePushCheckState module is not loaded
by any other check running prior to `FindLibEdit.cmake`:

    CMake Error at /var/no-tmpfs/portage/dev-util/lldb-15.0.4/work/cmake/Modules/FindLibEdit.cmake:24 (cmake_push_check_state):
      Unknown CMake command "cmake_push_check_state".
    Call Stack (most recent call first):
      cmake/modules/LLDBConfig.cmake:52 (find_package)
      cmake/modules/LLDBConfig.cmake:59 (add_optional_dependency)
      CMakeLists.txt:28 (include)

Gentoo Bug: https://bugs.gentoo.org/880065

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

(cherry picked from commit 3676a86a4322e8c2b9c541f057b5d3704146b8f3)

Reenable POSIX builtin library functions in gnu2x mode

gnu17 and earlier modes automatically expose several POSIX C APIs, and
this was accidentally disabled for gnu2x in
7d644e1215b376ec5e915df9ea2eeb56e2d94626.

This restores the behavior for gnu2x mode (without changing the
behavior in C standards modes instead of GNU modes).

Fixes #56607

[CMake] Fix -Wstrict-prototypes

Fixes warnings (or errors, if someone injects -Werror in their build system,
which happens in fact with some folks vendoring LLVM too) with Clang 16:
```
+/var/tmp/portage.notmp/portage/sys-devel/llvm-15.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: warning: a function declaration without a prototype
is deprecated in all versions of C [-Wstrict-prototypes]
-/var/tmp/portage.notmp/portage/sys-devel/llvm-14.0.4/work/llvm_build-abi_x86_64.amd64/CMakeFiles/CMakeTmp/src.c:3:9: error: a function declaration without a prototype is
deprecated in all versions of C [-Werror,-Wstrict-prototypes]
 int main() {return 0;}
         ^
          void
```

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

(cherry picked from commit 32a2af44e1e882f13d1cc2817f0a8d4d8b375d4d)

AMDGPU: Make various vector undefs legal

Surprisingly these were getting legalized to something
zero initialized.

This fixes an infinite loop when combining some vector types.
Also fixes zero initializing some undef values.

SimplifyDemandedVectorElts / SimplifyDemandedBits are not checking
for the legality of the output undefs they are replacing unused
operations with. This resulted in turning vectors into undefs
that were later re-legalized back into zero vectors.

(cherry picked from commit 7a84624079a2656c684bed6100708544500c5a32)

[clang][Sema] Fix a clang crash with btf_type_tag

For the following program,
  $ cat t.c
  struct t {
   int (__attribute__((btf_type_tag("rcu"))) *f)();
   int a;
  };
  int foo(struct t *arg) {
    return arg->a;
  }
Compiling with 'clang -g -O2 -S t.c' will cause a failure like below:
  clang: /home/yhs/work/llvm-project/clang/lib/Sema/SemaType.cpp:6391: void {anonymous}::DeclaratorLocFiller::VisitParenTypeLoc(clang::ParenTypeLoc):
         Assertion `Chunk.Kind == DeclaratorChunk::Paren' failed.
  PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace, preprocessed source, and associated run script.
  Stack dump:
  ......
  #5 0x00007f89e4280ea5 abort (/lib64/libc.so.6+0x21ea5)
  #6 0x00007f89e4280d79 _nl_load_domain.cold.0 (/lib64/libc.so.6+0x21d79)
  #7 0x00007f89e42a6456 (/lib64/libc.so.6+0x47456)
  #8 0x00000000045c2596 GetTypeSourceInfoForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0
  #9 0x00000000045ccfa5 GetFullTypeForDeclarator((anonymous namespace)::TypeProcessingState&, clang::QualType, clang::TypeSourceInfo*) SemaType.cpp:0:0
  ......

The reason of the failure is due to the mismatch of TypeLoc and D.getTypeObject().Kind. For example,
the TypeLoc is
  BTFTagAttributedType 0x88614e0 'int  btf_type_tag(rcu)()' sugar
  |-ParenType 0x8861480 'int ()' sugar
  | `-FunctionNoProtoType 0x8861450 'int ()' cdecl
  |   `-BuiltinType 0x87fd500 'int'
while corresponding D.getTypeObject().Kind points to DeclaratorChunk::Paren, and
this will cause later assertion.

To fix the issue, similar to AttributedTypeLoc, let us skip BTFTagAttributedTypeLoc in
GetTypeSourceInfoForDeclarator().

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

[SPARC] Make calls to function with big return values work

Implement CanLowerReturn and associated CallingConv changes for SPARC/SPARC64.

In particular, for SPARC64 there's new `RetCC_Sparc64_*` functions that handles the return case of the calling convention.
It uses the same analysis as `CC_Sparc64_*` family of funtions, but fails if the return value doesn't fit into the return registers.

This makes calls to functions with big return values converted to an sret function as expected, instead of crashing LLVM.

Reviewed By: MaskRay

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

(cherry picked from commit d3fcbee10d893b9e01e563c3840414ba89283484)

Take memset_inline into account in analyzeLoadFromClobberingMemInst

This appeared in https://reviews.llvm.org/D126903#3884061

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

(cherry picked from commit 1a726cfa83667585dd87a9955ed5e331cad45d18)

[lld-macho] Canonicalize personality pointers in EH frames

We already do this for personality pointers referenced from compact
unwind entries; this patch extends that behavior to personalities
referenced via EH frames as well.

This reduces the number of distinct personalities we need in the final
binary, and helps us avoid hitting the "too many personalities" error.

I renamed `UnwindInfoSection::prepareRelocations()` to simply `prepare`
since we now do some non-reloc-specific stuff within.

Fixes #58277.

Reviewed By: #lld-macho, oontvoo

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

(cherry picked from commit 7b45dfc6811a52ff4e9a6054dc276d70d77fddaf)

[clang][driver] Remove dynamic gcc-toolset/devtoolset logic

This breaks when the newest available devtoolset directory is not a
complete toolset: https://github.com/llvm/llvm-project/issues/57843

Remove this again in favor or just adding the two new directories for
devtoolset/gcc-toolset 12.

This reverts commit 35aaf548237a4f213ba9d95de53b33c5ce1eadce.
This reverts commit 9f97720268911abae2ad9d90e270358db234a1c1.

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

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

[clangd] Return earlier when snippet is empty

Fixes github.com/clangd/clangd/issues/1216

If the Snippet string is empty, Snippet.front() would trigger a crash.
Move the Snippet->empty() check up a few lines to avoid this. Should not
break any existing behavior.

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

(cherry picked from commit 60528c690a4c334d2a3a2c22eb97af9e67d7a91d)

[lldb]  Automatically unwrap parameter packs in template argument accessors

When looking at template arguments in LLDB, we usually care about what
the user passed in his code, not whether some of those arguments where
passed as a variadic parameter pack.

This patch extends all the C++ APIs to look at template parameters to
take an additional 'expand_pack' boolean that automatically unwraps the
potential argument packs. The equivalent SBAPI calls have been changed
to pass true for this parameter.

A byproduct of the patch is to also fix the support for template type
that have only a parameter pack as argument (like the OnlyPack type in
the test). Those were not recognized as template instanciations before.

The added test verifies that the SBAPI is able to iterate over the
arguments of a variadic template.

The original patch was written by Fred Riss almost 4 years ago.

Differential revision: https://reviews.llvm.org/D51387

(cherry picked from commit b706f56133a77f9d7c55270ac24ff59e6fce3fa4)

[SystemZ] Relase notes for LLVM 15

Unfortunately these notes were compiled until now, but these are the release notes for SystemZ.

(Did not find anything under clang)

@tstellar Should I push this patch onto release/15.x once approved, or will you apply it?

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

[ELF] Suppress "duplicate symbol" when resolving STB_WEAK and STB_GNU_UNIQUE in different COMDATs

```
template <typename T> struct A {
  A() {}
  int value = 0;
};

template <typename Value> struct B {
  static A<int> a;
};

template <typename Value> A<int> B<Value>::a;

inline int foo() {
  return B<int>::a.value;
}
```

```
clang++ -c -fno-pic a.cc -o weak.o
g++ -c -fno-pic a.cc -o unique.o  # --enable-gnu-unique-object

# Duplicate symbol error. In postParse, we do not check `sym.binding`
ld.lld -e 0 weak.o unique.o
```

Mixing GCC and Clang object files in this case is not ideal. .bss._ZGVN1BIiE1aE
has different COMDAT groups. It appears to work in practice because the guard
variable prevents harm due to double initialization.

For the linker, we just stick with the rule that a weak binding does not cause
"duplicate symbol" errors.

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

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

(cherry picked from commit 0051b6bb78772b0658f28e5f31ddf91c1589aab5)

[AutoUpgrade] Fix remangling when upgrading struct return type

This was remangling the old function rather than the new one, and
could result in failures when we were performing both a struct
return upgrade and an opaque pointer upgrade.

(cherry picked from commit c8938809d155682ef5eec170897b8c26b8cbf3ea)

Bump version to 15.0.4

[InstCombine] Bail out of casting calls when a conversion from/to byval is involved.

Fixes #58307

Reviewed By: nikic

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

(cherry picked from commit 86e57e66da9380eaa90a9d0830d7f2c5fe87af99)

[SROA] Don't speculate phis with different load user types

Fixes an SROA crash.

Fallout from opaque pointers since with typed pointers we'd bail out at the bitcast.

Reviewed By: nikic

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

(cherry picked from commit 6219ec07c6f8d1ead51beca7cf21fbf2323c51d7)

[test] Make Linux/sem_init_glibc.cpp robust

and fix it for 32-bit ports defining sem_init@GLIBC_2.0 (i386, mips32, powerpc32) for glibc>=2.36.

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

Reviewed By: mgorny

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

(cherry picked from commit 6f46ff3765dcdc178b9cf52ebd8c03437806798a)

[ARM] Fix for MVE i128 vector icmp costs.

We were hitting an assert as the legalied type needn't be a vector.

Fixes #58364

(cherry picked from commit de6dfbbb300e552efa1cd86a023063a39d408b06)

[clangd] Block clang-tidy misc-const-correctness check

This check performs an extremely large amount of work (for each variable, it
runs very many full matcher-driven traversals of the whole scope the variable
is defined in).

When (inadvertently) enabled for Fuchsia, it regressed BuildAST times by >10x
(400ms -> 7s on my machine).

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

(cherry picked from commit e78165f0ba1e2fbf72b36a36c8560645b69a168a)

[libc++] Fix std::function's handling of blocks under Objc ARC

Previously, some uses of std::function with blocks would crash when ARC was enabled.

rdar://100907096

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

(cherry picked from commit 0e4802bf45952b1120c52d4d1bf6bfa2800fd102)

[CMake] Provide Findzstd module

This module is used to find the system zstd library. The imported
targets intentionally use the same name as the generate zstd config
CMake file so these can be used interchangeably.

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

(cherry picked from commit 2d4fd0b6d5d5582ebb8b521d807104235d67aee4)

[llvm] [test] Add missing canonicalization of LLVM_ENABLE_ZSTD

Add LLVM_ENABLE_ZSTD to llvm_canonicalize_cmake_booleans().  This is
needed to ensure that the substitutions in lit.site.cfg.py resolve
to correct Python booleans.

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

(cherry picked from commit bc4bcbcfc820b324f680e8f260691c38052eedc9)

[llvm] [lit] Fix use_lld() to respect llvm_shlib_dir

Fix the use_lld() to use llvm_shlib_dir similarly to how use_clang()
does it.  This fixes use_lld() wrongly prepending llvm_libs_dir,
i.e. the directory with system-installed LLVM libraries before
the build directory of standalone build.  As a result, the shared
libraries from an earlier version of clang end up being used instead of
the newly built version when running the test suite prior to installing.

To reproduce the problem, build and install LLVM with dylibs first,
e.g.:

    cmake ../llvm -G Ninja -DCMAKE_BUILD_TYPE=MinSizeRel \
      -DCMAKE_INSTALL_PREFIX="${HOME}"/llvm-test \
      -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON \
      -DLLVM_INSTALL_UTILS=ON
    ninja install

Then build clang against that installation and run tests:

    export LD_LIBRARY_PATH=~/llvm-test/lib
    export PATh=~/llvm-test/bin:"${PATH}"
    cmake ../clang -G Ninja -DCMAKE_BUILD_TYPE=MinSizeRel \
      -DCMAKE_INSTALL_PREFIX="${HOME}"/llvm-test \
      -DCLANG_LINK_CLANG_DYLIB=ON -DLLVM_BUILD_TESTS=ON \
      -DLLVM_EXTERNAL_LIT="${PWD}"/bin/llvm-lit
    ninja check-clang

The tests will be run with LD_LIBRARY_PATH of:

    /home/${USER}/llvm-test/lib:/home/${USER}/llvm-project/build-clang/lib

As a result, installed libclang-cpp will take precedence over the one
from build dir.  With the patch, the correct path is used, i.e.:

    /home/${USER}/llvm-project/build-clang/lib:/home/${USER}/llvm-test/lib

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

(cherry picked from commit a64ea173d7b152678780d5443407d1071277642b)

[clang-tidy] Fix a false positive in readability-simplify-boolean-expr

Reviewed By: LegalizeAdulthood

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

(cherry picked from commit 8c783b8ec78ec857e446a89a35463baed8026f40)

[AArch64][SVE] Fix AArch64_SVE_VectorCall calling convention

This fixes the case where callees with SVE arguments outside of the z0-z7
range were incorrectly deduced as SVE calling convention functions

Revert "Recommit "[SCEV] Look through single value PHIs." (take 3)"

This reverts commit 20d798bd47ec5191de1b2a8a031da06a04e612e1.

This commit caused crashes in some cases, see github issue #58152.
This is fixed on main, but backporting it requires multiple
nontrivial cherrypicks.

Updating llvm/test/Transforms/LoopVectorize/create-induction-resume.ll
with update_test_checks.py, so this isn't an exact automatic revert,
as that test case was added after the reverted commit.

This fixes #58152 for the release branch.

Fix LLDB build on old Linux kernels (pre-4.1)

These fields are guarded elsewhere, but were missing here.

Reviewed By: wallace

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

(chery picked from a9ffb473453519bae158e5d9c72431aa0f6aac2b)

[Syntax] avoid using c++17 features on 15.x branch

Bump version to 15.0.3

[Syntax] Fix macro-arg handling in TokenBuffer::spelledForExpanded

A few cases were not handled correctly. Notably:
  #define ID(X) X
  #define HIDE a ID(b)
  HIDE
spelledForExpanded() would claim HIDE is an equivalent range of the 'b' it
contains, despite the fact that HIDE also covers 'a'.

While trying to fix this bug, I found findCommonRangeForMacroArgs hard
to understand (both the implementation and how it's used in spelledForExpanded).
It relies on details of the SourceLocation graph that are IMO fairly obscure.
So I've added/revised quite a lot of comments and made some naming tweaks.

Fixes https://github.com/clangd/clangd/issues/1289

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

(cherry picked from commit 67268ee11c220b1dfdf84afb10a12371c5ae6400)

[clangd] Improve inlay hints of things expanded from macros

When we aim a hint at some expanded tokens, we're only willing to attach it
to spelled tokens that exactly corresponde.

e.g.
int zoom(int x, int y, int z);
int dummy = zoom(NUMBERS);

Here we want to place a hint "x:" on the expanded "1", but we shouldn't
be willing to place it on NUMBERS, because it doesn't *exactly*
correspond (it has more tokens).

Fortunately we don't even have to implement this algorithm from scratch,
TokenBuffer has it.

Fixes https://github.com/clangd/clangd/issues/1289
Fixes https://github.com/clangd/clangd/issues/1118
Fixes https://github.com/clangd/clangd/issues/1018

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

(cherry picked from commit 924974a3a13b03090d04860f209ce11b3d9d00a6)

[X86] Remove AVX512VP2INTERSECT from Sapphire Rapids.

For more details, please refer to the latest ISE document: https://www.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html

Reviewed By: pengfei

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

(cherry picked from commit 566c277c64f8f76d8911aa5fd931903a357ed7be)

[clangd] Avoid scanning up to end of file on each comment!

Assigning char* (pointing at comment start) to StringRef was causing us
to scan the rest of the source file looking for the null terminator.

This seems to be eating about 8% of our *total* CPU!

While fixing this, factor out the common bits from the two places we're
parsing IWYU pragmas.

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

(cherry picked from commit 5d2d527c32da2081b814ef8b446bc3e037f74b0a)

[LoopVersioning] Invalidate SCEV for phi if new values are added.

After 20d798bd47ec5191d, SCEV looks through PHIs with a single incoming
value. This means adding a new incoming value may change the SCEV for a
phi. Add missing invalidation when an existing PHI is reused during
LoopVersioning. New incoming values will be added later from the
versioned loop.

Similar issues have been fixed by also adding missing invalidation.

Fixes #57825.

Note that the test case unfortunately requires running loop-vectorize
followed by loop-load-elimination, which does the actual versioning. I
don't think it is possible to reproduce the failure without that
combination.

(cherry picked from commit 623c4a7a55f716b96070a5c2f83fe0096cb38d38)

[clang-tools-extra] [clangd] Respect llvm_shlib_dir in tests

Add llvm_shlib_dir to variables used in clangd test suite, consistently
to how it is used in the test suites of clang, clang-tools-extra
and a few other components.  This is necessary to ensure that
the correct shared libraries are used when building clang standalone --
otherwise, use_clang() sets LD_LIBRARY_PATH to the directory containing
the earlier system installation of clang rather than the just-built
library.

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

(cherry picked from commit 77945a344c3dee3f9735744c8d4151ef2cec6a8d)

use LLVM_USE_STATIC_ZSTD

removes LLVM_PREFER_STATIC_ZSTD in favor of using a LLVM_USE_STATIC_ZSTD

Reviewed By: phosek

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

(cherry picked from commit fc1da043f4f9198303abd6f643cf23439115ce73)

tweak zstd behavior in cmake and llvm config for better testing

add LLVM_PREFER_STATIC_ZSTD (default TRUE) cmake config flag
(compression test seems to fail for shared zstd on windows, note that zstd multithread is by default disabled in the static build so it may be a hidden variable)
propagate variable zstd_DIR in LLVMConfig.cmake.in
fix llvm-config CMakeLists.txt behavior for absolute libs windows
get zstd lib name

Reviewed By: phosek

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

(cherry picked from commit c0b4f248df79f184adba856f13a950a53c881f3f)

[clang][DebugInfo] Emit debuginfo for non-constant case value

Currently, clang does not emit debuginfo for the switch stmt
case value if it is an enum value. For example,
  $ cat test.c
  enum { AA = 1, BB = 2 };
  int func1(int a) {
    switch(a) {
    case AA: return 10;
    case BB: return 11;
    default: break;
    }
    return 0;
  }
  $ llvm-dwarfdump test.o | grep AA
  $
Note that gcc does emit debuginfo for the same test case.

This patch added such a support with similar implementation
to CodeGenFunction::EmitDeclRefExprDbgValue(). With this patch,
  $ clang -g -c test.c
  $ llvm-dwarfdump test.o | grep AA
                  DW_AT_name    ("AA")
  $

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

(cherry picked from commit 75be0482a2e2a78fae83f1ca604f4ee20d673796)

[gn build] (manually) port 18b4a8bcf35 more

(cherry picked from commit dd428a571c69621d5b6eb2e0e3ce5497c304fb2c)

[LV] Update handling of scalable pointer inductions after b73d2c8.

The dependent code has been changed quite a lot since 151c144 which
b73d2c8 effectively reverts. Now we run into a case where lowering
didn't expect/support the behavior pre 151c144 any longer.

Update the code dealing with scalable pointer inductions to also check
for uniformity in combination with isScalarAfterVectorization. This
should ensure scalable pointer inductions are handled properly during
epilogue vectorization.

Fixes #57912.

(cherry picked from commit 2c692d891ed639779b1c4b504ca63037bbacc0e8)

[LV] Add test for #57912.

Add test showing miscompilation during epilogue vectorization with SVE.

(cherry picked from commit 17167005d532dce35ade3a47a0403ffaa7fff6ff)

[LV] Convert sve-epilog-vect.ll to use opaque pointers.

(cherry picked from commit 05b3493819fa8aba1eb7510afbcb80a64148beb6)

[Clang] Fix variant crashes from GH58028, GH57370

Fixes a null dereference in some diagnostic issuing code.

Closes https://github.com/llvm/llvm-project/issues/57370
Closes https://github.com/llvm/llvm-project/issues/58028

Reviewed By: shafik

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

(cherry picked from commit 9415aad6a40fec74296008a25f34164a95c857f4)

[ValueTracking] Fix CannotBeOrderedLessThanZero() for fdiv (PR58046)

When checking the RHS of fdiv, we should set the SignBitOnly flag,
because a negative zero can become -Inf, which is ordered less
than zero.

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

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

[InstSimplify] Add test for PR58046 (NFC)

[libcxx] Make stdatomic.h work when included from a C source file

If a C source file includes the libc++ stdatomic.h, compilation will
break because (a) the C++ standard check will fail (which is expected),
and (b) `_LIBCPP_COMPILER_CLANG_BASED` won't be defined because the
logic defining it in `__config` is guarded by a `__cplusplus` check, so
we'll end up with a blank header. Move the detection logic outside of
the `__cplusplus` check to make the second check pass even in a C context
when you're using Clang. Note that `_LIBCPP_STD_VER` is not defined when
in C mode, hence stdatomic.h needs to check if in C++ mode before using
that macro to avoid a warning.

In an ideal world, a C source file wouldn't be including the libc++
header directory in its search path, so we'd never have this issue.
Unfortunately, certain build environments make this hard to guarantee,
and in this case it's easy to tweak this header to make it work in a C
context, so I'm hoping this is acceptable.

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

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

(cherry picked from commit afec0f0ec38a72bcc6a697c1cefb1dac0bbd02fb)

[docs] improve documentation for misc-const-correctness

Improve the documentation for 'misc-const-correctness' to:

- include better examples
- improve the english
- fix links to other checks that were broken due to the directory-layout changes
- mention the limitation that the check does not run on `C` code.

Addresses #56749, #56958

Reviewed By: njames93

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

(cherry picked from commit b5b750346346bfe95c7c6b1cceacc6cfccc8f4f4)

[clang-tidy] adjust treating of array-of-pointers when 'AnalyzePointers' is deactivated

'misc-const-correctness' previously considered arrays as 'Values' independent of the type of the elements.
This is inconsistent with the configuration of the check to disable treating pointers as values.
This patch rectifies this inconsistency.

Fixes #56749

Reviewed By: njames93

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

(cherry picked from commit e66345d54d5f5e803f54c1ace487d57bb11ee884)

Fix build error in StmtPrinterTest.cpp

(cherry picked from commit c933453858307d060a1b79e257feb99c9ac828d7)

[clangd] Avoid crash when printing call to string literal operator template

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

(cherry picked from commit 898c421975ed36b99ec2047589384539bd29a40b)

[ELF] Rewrite R_RISCV_ALIGN nops when r.addend%4 != 0

For RVC, GNU assembler and LLVM integrated assembler add c.nop followed by a
sequence of 4-byte nops. Even if remove % 4 == 0, we have to split one 4-byte
nop and therefore need to write the code sequence, otherwise we create an
incorrect c.unimp.

(cherry picked from commit 78084d9e77b9a2017e2215491b71b37c2671c292)

Bump version to 15.0.2

Exclude check-polly-unittests and check-polly-isl from check-all

The unittests are already included in check-polly, so check-all was
running them twice.  Running them twice causes a race on the output
files, which led to intermittent failures on the reverse-iteration
buildbot.

(cherry picked from commit 2c29268bfcc84c3b94bcb0aa34b7ef9c9bd9af01)

[Hexagon] Add defaulted operator= to classes with defaulted copy ctor

This avoids deprecation warning:
```
warning: definition of implicit copy assignment operator for 'AddrInfo'
is deprecated because it has a user-declared copy constructor
[-Wdeprecated-copy]
```

This fixes https://github.com/llvm/llvm-project/issues/57229

(cherry picked from commit 252cea037bcad6e1e7236756bcbb4e4ed73e328d)

[MachineCycle][NFC] add a cache for block and its top level cycle

This solves https://github.com/llvm/llvm-project/issues/57664

Reviewed By: sameerds

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

(cherry picked from commit c941d925b0e47ec166364178edac75cf1cb1ee1a)

[libc++] Keep unary_function and binary_function in C++17 for one more release

In LLVM 15, we added the deprecation markup for unary_function and
binary_function for >= C++11, and we also removed it for >= C++17.
While this is in accordance with the Standard, it's also a bit quick
for our users, since there was no release in which the classes were
marked as deprecated before their removal.

We noticed widespread breakage due to this, and after months of trying
to fix downstream failures, I am coming to the conclusion that users
will be better served if we give them one release where unary_function
is deprecated but still provided even in >= C++17.

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

SPIRV: Fix compilation in NDEBUG.

(cherry picked from commit 59351fe340f20a605bae53260ed30a8e0fd95cb6)

[LV] Keep track of cost-based ScalarAfterVec in VPWidenPointerInd.

Epilogue vectorization uses isScalarAfterVectorization to check if
widened versions for inductions need to be generated and bails out in
those cases.

At the moment, there are scenarios where isScalarAfterVectorization
returns true but VPWidenPointerInduction::onlyScalarsGenerated would
return false, causing widening.

This can lead to widened phis with incorrect start values being created
in the epilogue vector body.

This patch addresses the issue by storing the cost-model decision in
VPWidenPointerInductionRecipe and restoring the behavior before 151c144.
This effectively reverts 151c144, but the long-term fix is to properly
support widened inductions during epilogue vectorization

Fixes #57712.

[LV] Move new epilog-vectorization-widen-inductions.ll to AArch64 dir.

The test requires the AArch64 backend, so move it to the right subdir.

[LV] Add tests for epilogue vectorization with widened inductions.

Includes a test for the miscompile in #57712.

[libc++] Always query the compiler to find whether a type is always lockfree

In https://llvm.org/D56913, we added an emulation for the __atomic_always_lock_free
compiler builtin when compiling in Freestanding mode. However, the emulation
did (and could not) give exactly the same answer as the compiler builtin,
which led to a potential ABI break for e.g. enum classes.

After speaking to the original author of D56913, we agree that the correct
behavior is to instead always use the compiler builtin, since that provides
a more accurate answer, and __atomic_always_lock_free is a purely front-end
builtin which doesn't require any runtime support. Furthermore, it is
available regardless of the Standard mode (see https://godbolt.org/z/cazf3ssYY).

However, this patch does constitute an ABI break. As shown by https://godbolt.org/z/1eoex6zdK:
- In LLVM <= 11.0.1, an atomic<enum class with 1 byte> would not contain a lock byte.
- In LLVM >= 12.0.0, an atomic<enum class with 1 byte> would contain a lock byte.

This patch breaks the ABI again to bring it back to 1 byte, which seems
like the correct thing to do.

Fixes #57440

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

(cherry picked from commit f1a601fe88f99d52ca80617266897b217bcd4d64)

[docs] Fix build-docs.sh

If libcxxabi is not included CMake will error out:

Cannot find target libcxxabi-SHARED

I ran into this doing the 15.0.0 release

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