```
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 0051b6bb)

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 c8938809)

Fixes #58307

Reviewed By: nikic

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

(cherry picked from commit 86e57e66)

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 6219ec07)

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 6f46ff37)

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

Fixes #58364

(cherry picked from commit de6dfbbb)

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 e78165f0)

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 0e4802bf)

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 2d4fd0b6)

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 bc4bcbcf)

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 a64ea173)

Reviewed By: LegalizeAdulthood

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

(cherry picked from commit 8c783b8e)

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

This reverts commit 20d798bd.

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.

These fields are guarded elsewhere, but were missing here.

Reviewed By: wallace

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

(chery picked from a9ffb473)

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 67268ee1)

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 924974a3)

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 566c277c)

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 5d2d527c)

After 20d798bd, 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 623c4a7a)

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 77945a34)

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 fc1da043)

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 c0b4f248)

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 75be0482)

(cherry picked from commit dd428a57)

The dependent code has been changed quite a lot since 151c1443 which
b73d2c8c effectively reverts. Now we run into a case where lowering
didn't expect/support the behavior pre 151c1443 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 2c692d89)

Add test showing miscompilation during epilogue vectorization with SVE.

(cherry picked from commit 17167005)

(cherry picked from commit 05b34938)

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 9415aad6)

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

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 afec0f0e)

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 b5b75034)

'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 e66345d5)

(cherry picked from commit c9334538)

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

(cherry picked from commit 898c4219)

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 78084d9e)