Also, fix checking of first line in ::parse.  We can't use the
::getLines helper here since that already does comment stripping
internally.

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

(cherry picked from commit d9d840cd)

The previous code incorrectly assumed that we would never call
warnBracedScalarInit(...) with a EK_ParenAggInitMember. This patch fixes
the bug by warning when a scalar member is initialized via a braced-init
list when performing a parentehsized aggregate initialization. This
behavior is consistent with parentehsized list aggregate initialization.

Fixes #63008

Reviewed By: shafik

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

Comparison between two AliasResults implicitly decayed to comparison
of AliasResult::Kind. As a result, MergeAliasResults() ended up
considering two PartialAlias results with different offsets as
equivalent.

Fix this by adding an operator== implementation. To stay
compatible with extensive use of comparisons between AliasResult
and AliasResult::Kind, add an overload for that as well, which
will ignore the offset. In the future, it would probably be a
good idea to remove these implicit decays to AliasResult::Kind
and add dedicated methods to check for specific AliasResult kinds.

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

(cherry picked from commit 97f0e7b0)

(cherry picked from commit 4d64ffa9)

Reviewed By: RKSimon

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

(cherry picked from commit 801dd887)

In LoongArch ABI spec, we can see that in the LP64D ABI, unsigned 32-bit
types, such as unsigned int, are stored in general-purpose registers as
proper sign extensions of their 32-bit values.

Reference:
https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html#_abi_lp64d

Reviewed By: SixWeining, xen0n

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

(cherry picked from commit fe6716a4)

See the docs in lld/docs/WebAssembly.rst for more on this.

This feature unlocks a lot of simplification in the emscripten toolchain
since we can represent the JS libraries to wasm-ld as stub libraries.

See https://github.com/emscripten-core/emscripten/issues/18875

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

(cherry picked from commit 3111784f)

See https://reviews.llvm.org/D109572 for the original ELF version.

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

(cherry picked from commit 8aef04fa)

Fixes #62087

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

(cherry picked from commit 2bb7e00b)

Before this patch it was expected that if there was several immediate
invocations they all belong to the same expression evaluation context.
During parsing of non local variable initializer a new evaluation context is
pushed, so code like this
```
namespace scope {
struct channel {
    consteval channel(const char* name) noexcept { }
};
consteval const char* make_channel_name(const char* name) { return name;}

channel rsx_log(make_channel_name("rsx_log"));
}
```
produced a nested immediate invocation whose subexpressions are attached
to different expression evaluation contexts. The constructor call
belongs to TU context and `make_channel_name` call to context of
variable initializer.

This patch removes this assumption and adds tracking of previously
failed immediate invocations, so it is possible when handling an
immediate invocation th check that its subexpressions from possibly another
evaluation context contains errors and not produce duplicate
diagnostics.

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

Reviewed By: aaron.ballman, shafik

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

(cherry picked from commit a5e1a93e)

Recent commit https://github.com/llvm/llvm-project/commit/8f833f88ab78265a8e0ebb0d1522771d67c708a9 modified the installation rpath and did not set `BUILD_WITH_INSTALL_RPATH` correctly on AIX, which led to installation failures on AIX. This patch sets `BUILD_WITH_INSTALL_RPATH` on AIX to fix the installation failures.

Reviewed By: buttaface, daltenty

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

(cherry picked from commit 887828d5)

If any LLVM subprojects are built separately, the LLVM build directory
LLVM_LIBRARY_DIR is added to both the build and install runpaths in
llvm_setup_rpath(), which is incorrect when installed. Separate the
build and install runpaths on ELF platforms and finally remove the
incorrect call to this function for compiler-rt, as previously attempted
in 21c008d5. That prior attempt was reverted in 959dbd17, where it
was said to break the build on macOS and Windows, so I made sure to keep
those platforms the same.

Two examples of incorrect runpaths that are currently added, one from
the latest LLVM 16 toolchain for linux x86_64:

  > readelf -d clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.*so | ag "File:|runpath"
  File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.so
  0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
  File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.dyndd.so
  0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
  File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.hwasan_aliases.so
  0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
  File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.hwasan.so
  0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
  File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.memprof.so
  0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
  File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.scudo_standalone.so
  0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
  File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.tsan.so
  0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
  File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.ubsan_minimal.so
  0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]
  File: clang+llvm-16.0.0-x86_64-linux-gnu-ubuntu-18.04/lib/clang/16/lib/x86_64-unknown-linux-gnu/libclang_rt.ubsan_standalone.so
  0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/tmp/llvm_release/final/Phase3/Release/llvmCore-16.0.0-final.obj/./lib]

Another is in the Swift toolchain, which builds lldb separately:

  > readelf -d swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/{bin/lldb*,lib/liblldb.so}|ag "File:|runpath"
  File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb
  0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib]
  File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb-argdumper
  0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib]
  File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/bin/lldb-server
  0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib]
  File: swift-5.9-DEVELOPMENT-SNAPSHOT-2023-03-24-a-ubuntu20.04/usr/lib/liblldb.so
  0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/home/build-user/build/buildbot_linux/llvm-linux-x86_64/./lib:/home/build-user/build/buildbot_linux/swift-linux-x86_64/lib/swift/linux:$ORIGIN/../lib/swift/linux]

This patch should fix this problem of absolute paths from the build host
leaking out into the toolchain's runpaths.

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

(cherry picked from commit 8f833f88)

Revert "[clangd] Fix builds after 4ddae8b9"

This reverts commit ae42196b.

Revert "[clangd] Fix test failure when it's built with compiler flags unknown by clang"

This reverts commit 21f3dfbc.

Revert "[cmake] Disable GCC lifetime DSE"

This reverts commit d5cce0a7.

Revert "[clang-tidy][test] Add trailing -- to suppress compile_commands.json read"

This reverts commit 57262bbd.

Before this patch, initialized class members would have the LifetimeKind
LK_MemInitializer, which does not allow for binding a temporary to a
reference. Binding to a temporary however is allowed in parenthesized
aggregate initialization, even if it leads to a dangling reference. To
fix this, we create a new EntityKind, EK_ParenAggInitMember, which has
LifetimeKind LK_FullExpression.

This patch does *not* attempt to diagnose dangling references as a
result of using this feature.

This patch also refactors TryOrBuildParenListInitialization(...) to
accomodate creating different InitializedEntity objects.

Fixes #61567

[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p0960r3.html

Reviewed By: shafik

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

Fixes "dependent projects fail to build with cmake 3.25 and llvm 16-rc4".

When building [latest `iovisor/bcc`](https://github.com/iovisor/bcc/commit/1ea0390725391e76256af6a4d0eb857816e6290f), `cmake` complains about a change in the behavior of operator `IN_LIST`:
```console
CMake Warning (dev) at /usr/local/lib/cmake/llvm/LLVM-Config.cmake:230 (if):
  Policy CMP0057 is not set: Support new IN_LIST if() operator.  Run "cmake
  --help-policy CMP0057" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  IN_LIST will be interpreted as an operator when the policy is set to NEW.
  Since the policy is not set the OLD behavior will be used.
Call Stack (most recent call first):
  cmake/clang_libs.cmake:32 (llvm_map_components_to_libnames)
  src/cc/CMakeLists.txt:132 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

CMake Error at /usr/local/lib/cmake/llvm/LLVM-Config.cmake:230 (if):
  if given arguments:

    "engine" "IN_LIST" "link_components"

  Unknown arguments specified
Call Stack (most recent call first):
  cmake/clang_libs.cmake:32 (llvm_map_components_to_libnames)
  src/cc/CMakeLists.txt:132 (include)
```

This patch addresses this issue by setting the aforementioned policy in `LLVM-Config.cmake`.

Reviewed By: mgorny, thesamesam

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

Closes: https://github.com/llvm/llvm-project/issues/61436
(cherry picked from commit 75a0502f)

Fixes #62679.

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

(cherry picked from commit a72b064a)

This addresses https://github.com/llvm/llvm-project/issues/62748.

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

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

(cherry picked from commit c7b291a6)

Parsing instruments and analysis regions causes us to see the same
labels two times since we parse the same file twice under the same
context.

This change creates a seperate context for instrument parsing
and another for analysis region parsing. I will post a follow up
commit once I get some free cycles to parse analysis regions and
instruments in one parsing pass under a single context.

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

(cherry picked from commit 1c2b8129)

Fixes unexpected warning.

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

(cherry picked from commit 2f0a1699)

This reverts commit 3b6f7e45.

See comments on D150645.

(cherry picked from commit 3d7903f1)

Instead of failing to select during isel, drop the intrinsic in
lowering.

Fixes PR62839.

Reviewed By: pengfei

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

(cherry picked from commit 022aefa5)

circumstances when parsing ASTs

Fix ArgsAsWritten being null for ConceptSpecializationExpr in certain
circumstances when parsing ASTs

ASTStmtWriter::VisitConceptSpecializationExpr specifically expects
getTemplateArgsAsWritten() to return true, which it wasn't when parsed
by ASTContext.cpp in certain edge cases.

Fixes: #61486

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

(cherry picked from commit 1f48a1fc)

Add additional overload to prevent API break.

Reviewed By: thieta

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

(cherry picked from commit afa607fb)

(cherry picked from commit 9ffef0f2)

If LLVM is built with a compiler other than clang, the `compile_commands.json`
file may contain compiler flags unknown by clang.  When a clangd test is copied
into the build directory and checked, clangd will pick the unknown flag from
the file and cause a test failure.  Create an empty `compile_commands.json` in
the test directory nested in the build directory to override it.

Reviewed By: thesamesam

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

(cherry picked from commit 4ddae8b9)

When running bcc tool execsnoop ([1]) which is built with latest llvm,
I hit the following error:
  $ sudo ./execsnoop.py
  /virtual/main.c:99:157: error: expected ')'
    data.ppid = ({ typeof(pid_t) _val; __builtin_memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val),
       (void *)&({ typeof(struct task_struct  btf_type_tag(rcu)*) _val; __builtin_memset(&_val, 0, sizeof(_val));
                                              ^
        bpf_probe_read(&_val, sizeof(_val), (void *)&task->real_parent); _val; })->tgid); _val; });

The failure reason is due to that the bcc rewriter printed type like
  struct task_struct  btf_type_tag(rcu)*
where the compiler cannot recognize what 'btf_type_tag(rcu)' is.

The above type is printed in [2] by UnaryOperator->getType().getAsString() (from clang)
in function ProbeVisitor::VisitUnaryOperator.

The original source type looks like ([3])
  struct task_struct {
    ...
    struct task_struct __rcu	*real_parent;
    ...
  }
  where '__rcu' is a macro expanding to '__attribute__((btf_type_tag("rcu")))'.

Let us print btf_type_tag properly in clang so bcc tools and broader type printing
will work properly.

With this patch, the above rewrited source code looks like
    data.ppid = ({ typeof(pid_t) _val; __builtin_memset(&_val, 0, sizeof(_val)); bpf_probe_read(&_val, sizeof(_val),
       (void *)&({ typeof(struct task_struct  __attribute__((btf_type_tag("rcu")))*) _val; __builtin_memset(&_val, 0, sizeof(_val));
        bpf_probe_read(&_val, sizeof(_val), (void *)&task->real_parent); _val; })->tgid); _val; });

and execsnoop.py tool can run properly.

  [1] https://github.com/iovisor/bcc/blob/master/tools/exitsnoop.py
  [2] https://github.com/iovisor/bcc/blob/master/src/cc/frontends/clang/b_frontend_action.cc
  [3] https://github.com/torvalds/linux/blob/master/include/linux/sched.h

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

(cherry picked from commit 30603049)

This code detected that the type returned from getShiftAmountTy was
too small to hold the constant shift amount. But it used the full
type size instead of scalar type size leading it to crash for
scalable vectors.

This code was necessary when getShiftAmountTy would always
return the target preferred shift amount type for scalars even when
the type was an illegal type larger than the target supported. For
vectors, getShiftAmountTy has always returned the vector type.

Fortunately, getShiftAmountTy was fixed a while ago to detect that
the target's preferred size for scalars is not large enough for the
type. So we can delete this code.

Switched to use getShiftAmountConstant to further simplify the code.

Fixs PR61561.

(cherry picked from commit a37df84f)

Reviewed By: rnk

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

(cherry picked from commit 3b6f7e45)

LLVM data structures like llvm::User and llvm::MDNode rely on
the value of object storage persisting beyond the lifetime of the
object (#24952).  This is not standard compliant and causes a runtime
crash if LLVM is built with GCC and LTO enabled (#57740).  Until
these issues are fixed, we need to disable dead store eliminations
eliminations based on object lifetime.

The previous test issues are fixed by 626849c7.

Bug: https://github.com/llvm/llvm-project/issues/24952
Bug: https://github.com/llvm/llvm-project/issues/57740
Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106943

Reviewed By: MaskRay, thesamesam, nikic

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

(cherry picked from commit 47f5c54f)

This fixes some build bots if we reland D150505: specifically when using GCC to
build LLVM and then `-fno-lifetime-dse` ends up passed to compile_commands.json
and causing clang-tidy to pick up the Clang unknown option.

(cherry picked from commit 626849c7)

The x86_intrcc calling convention will build two STACKALLOC_W_PROBING machine instructions if the function takes an error code. This is caused by an additional call to emitSPUpdate in llvm/lib/Target/X86/X86FrameLowering.cpp:1650. Previously only the first STACKALLOC_W_PROBING machine instruction was properly handled, the second one was simply ignored. This lead to miscompilations where the stack pointer wasn't properly updated (see https://github.com/rust-lang/rust/issues/109918). This patch fixes this by handling all STACKALLOC_W_PROBING machine instructions.

To be honest I don't quite understand why this didn't lead to more noticeable miscompilations previously.

This is my first time contributing to LLVM.

Reviewed By: pengfei

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

(cherry picked from commit f6154364)

D142279 enabled assertion in libstdc++ and one was triggered
in the PFTBuilder because an optional was access even if it was
null.
This patch fix this issue and add a regression test.

Reviewed By: jeanPerier

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

(cherry picked from commit 3f55311a)

Previously, when checking whether an in-class initializer exists when
performing parenthesized aggregate initialization, Clang checks that the
output of FieldDecl::getInClassInitializer() is non-null. This is
incorrect; if the field is part of a templated type, then
getInClassInitializer() will return nullptr if we haven't called
Sem::BuildCXXDefaultInitExpr(...) before, even if
FieldDecl::hasInClassInitializer() returns true. The end result is that
Clang incorrectly ignores the in class initializer and
value-initializes the field. The fix therefore is to instead call
FieldDecl::hasInClassInitializer(), which is what we do for braced init
lists [0].

Before this patch, Clang does correctly recognize the in-class field
initializer in certain cases. This is Sema::BuildCXXDefaultInitExpr(...)
populates the in class initializer of the corresponding FieldDecl
object. Therefore, if that method was previously called with the same
FieldDecl object, as can happen with a decltype(...) or a braced list
initialization, FieldDecl::getInClassInitializer() will return a
non-null expression, and the field becomes properly initialized.

Fixes 62266

[0]: https://github.com/llvm/llvm-project/blob/be5f35e24f4c15caf3c4aeccddc54c52560c28a0/clang/lib/Sema/SemaInit.cpp#L685

Reviewed By: shafik

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

The new test case showed that the NoPHIs flag needs to be cleared.

Original commit message:

[SystemZ] Bugfix in expansion of memmem operations.

Since NC, OC, and XC clobber CC, the EXRL_Pseudo targeting these must also be
marked to do so.

Original patch by uweigand.

Reviewed by: uweigand

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

Fixes: https://github.com/llvm/llvm-project/issues/62572
(cherry picked from commit 655f0fc4)

Mark the two dfsan tests that are known to be broken on glibc-2.37
as XFAIL, to make the test suite start passing on Gentoo again.

Bug: https://github.com/llvm/llvm-project/issues/60678

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

(cherry picked from commit 488a4b24)

Currently the driver does not propagate the `-f[no-]emulated-tls` flags
to the linker under LTO. This can be surprising when the platform
defaults differ from the flags being passed. A related discussion can be
found in https://reviews.llvm.org/D143619. While the focus there was
RISC-V support, the root cause was that setting `-femualted-tls` and
`-flto` when compiling with Clang resulted in missing symbols because
the platform defaults for Android differed from the flags being passed
to Clang.

This patch changes the Clang driver's behavior to pass the emulated-tls
flags through to the linker when compiling with LTO/ThinLTO.

Reviewed By: phosek, vit9696

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

(cherry picked from commit a78816a6)