Fixed a false positive where a lambda expression in the condition which contained an assignement would trigger a warning.
Fixes #56729

Reviewed By: gribozavr2

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

Otherwise when we visit all libcalls in
updateCGAndAnalysisManagerForPass(), the old libcall is dead and doesn't
have a node.

We treat libcalls conservatively in LazyCallGraph because any function
may introduce calls to them out of thin air.

It is weird to change the signature of a libcall since introducing calls
to the libcall with a different signature may break, but other passes
like deadargelim already do it, so let's preserve this behavior for now.

Fixes an issue found in D128830.

Reviewed By: psamolysov

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

This patch replaces getLCMSize with std::lcm, a C++17 feature.

Note that all the arguments are of unsigned with no implicit type
conversion as they are passed to getLCMSize.

This patch replaces mlir::lcm with std::lcm, a C++17 feature.

Note that all the arguments to mlir::lcm are of int64_t with no
implicit type conversion as they are passed to mlir::lcm, which I've
verified by modifying mlir::lcm as:

  template <typename TA, typename TB>
  inline int64_t lcm(TA a, TB b) {
    static_assert(std::is_same_v<TA, int64_t>);
    static_assert(std::is_same_v<TB, int64_t>);
    :

This patch replaces clamp idioms with std::clamp where the range is
obviously valid from the source code (that is, low <= high) to avoid
introducing undefined behavior.

SAVE statements referencing COMMON block names are not allowed in BLOCK
constructs. If they occur, an error is correctly emitted, but then flang
gets confused by the illegal SAVE and produces a faulty warning. This
patch removes that warning.

Consider this piece of Fortran (from the test blockconstruct02.f90):

program  main
  real r, s, t
  common /argmnt2/ r, s, t
  block
    save /argmnt2/
  end block
end program

Here flang (in addition to the error about the illegal SAVE) emits a
portability warning saying that the two definitions of argmnt2 have
different size, which does not make much sense.

This patch is a prerequisite for D125804, which in turn will make
blockconstruct02.f90 test this patch.

Reviewed By: jeanPerier

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

If the shift constant has undefined lanes, we can assume those
are the same as the defined lanes in these transforms:
https://alive2.llvm.org/ce/z/t6TTJ2

Replace undef with poison in the test while here to support
the transition away from undef.

issue #57381

Signed-off-by: Jun Zhang <jun@junz.org>

If we run into a first usage or definition of a mangled name, and
there's a DeferredDecl that associated with it, we should remember it we
need to emit it later on.

Without this patch, clang-repl hits a JIT symbol not found error:
clang-repl> extern "C" int printf(const char *, ...);
clang-repl> auto l1 = []() { printf("ONE\n"); return 42; };
clang-repl> auto l2 = []() { printf("TWO\n"); return 17; };
clang-repl> auto r1 = l1();
ONE
clang-repl> auto r2 = l2();
TWO
clang-repl> auto r3 = l2();
JIT session error: Symbols not found: [ l2 ]
error: Failed to materialize symbols: { (main,
{ r3, orc_init_func.incr_module_5, $.incr_module_5.inits.0 }) }

Signed-off-by: Jun Zhang <jun@junz.org>

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

0 - (zext (i8 X u>> 7) to iN) --> sext (i8 X s>> 7) to iN

https://alive2.llvm.org/ce/z/jzv4Ud

This is part of solving issue #57381.

issue #57381

Changes the CI to use the Clang 16 nightly builds instead of Clang 14.
(The libc++15 branch was accidentally build using Clang 14 instead of
Clang 15; hence the skipping of a number.)

Also adds a Clang 15 build to the test matrix.

Based on the private discussion with @ldionne we decided to move
the configuration parameters from the `run-buildbot` script to the
CI configuration `buildkite-pipeline.yml`. Other hard-coded values
from the Dockerfile should be move to the CI configuration too. That
will be done in another commit.

C++17 will use Clang-15 since D131479 causes a test to fail.

Reviewed By: ldionne, #libc

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

This section is marked S_ATTR_LIVE_SUPPORT in input files, which meant
that on arm64, we were unnecessarily preserving FDEs if we e.g. had
multiple weak definitions for a function. Worse, we would actually
produce an invalid `__eh_frame` section in that case, because the CIE
associated with the unnecessary FDE would still get dead-stripped and
we'd end up with a dangling FDE. We set up associations from functions
to their FDEs, so dead-stripping will just work naturally, and we can
clear S_ATTR_LIVE_SUPPORT from our input `__eh_frame` sections to fix
dead-stripping.

Reviewed By: #lld-macho, int3

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

Reviewed By: ldionne, #libc

Spies: STL_MSFT, CaseyCarter, huixie90, libcxx-commits

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

A value of 'workitemid / wavefrontize' or 'workitemid & (wavefrontize - 1)'
is wave uniform.

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

I noticed that `test/asan/Unit/lit.site.cfg.py.in` contains two typos,
using the FreeBSD forms of the `LD_*LIBRARY_PATH*` variables on Solaris.

Tested on `amd64-pc-solaris2.11`.

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

MapperJITLinkMemoryManager has slab allocation. Combined with
InProcessMapper, it can replace InProcessMemoryManager.

It can also replace JITLinkSlabAllocator through the InProcessDeltaMapper
that adds an offset to the executor addresses for use in tests.

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

The source of the flakyness is internal uninitialized buffers due to
a dangling variable in the model.

The page for fuzzing LLDB had incorrectly formatted code,
this commit fixes that.

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

SharedMemoryMapper assumed each reservation will have its corresponding
allocations starting from the beginning. However with the introduction
of the slab allocator, there can be a possible offset from the start
from where the initialization is being performed.

This commit also simplifies the logic for finding the parent reservation
and makes the assert messages consistent.

The command to detect whether the stash is needed is `git status --porcelain`
which includes untracked files by default. We want to stash untracked files
as well as they may affect compilation (LLVM CMake checks that all source files
should be included in CMakeLists).

Update the stash command to include untracked files as well.

Reviewed By: #bolt, rafauler

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

This utility was a substitute for std::apply, which is now available.

This commit adds a new page to the LLDB HTML documentation for the LLDB
fuzzers. The page primarily explains what the fuzzers are as well as how
to build them, run them and investigate and reproduce bugs.

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

Depends on D132761.

Reviewed By: eugenis

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

Fixes this test compile error:
```
<path>/compiler-rt/test/tsan/debug_alloc_stack.cpp:54:7: error: no matching function for call to '__tsan_get_alloc_stack'
      __tsan_get_alloc_stack(mem, trace, num_frames, &thread_id, &thread_os_id);
      ^~~~~~~~~~~~~~~~~~~~~~
<path>/compiler-rt/test/tsan/debug_alloc_stack.cpp:17:16: note: candidate function not viable: no known conversion from 'uint64_t **' (aka 'unsigned long long **') to 'uint64_t *' (aka 'unsigned long long *') for 5th argument; remove &
extern "C" int __tsan_get_alloc_stack(void *addr, void **trace, size_t size,
               ^
<path>/compiler-rt/test/tsan/debug_alloc_stack.cpp:61:46: warning: format specifies type 'unsigned long long' but the argument has type 'uint64_t *' (aka 'unsigned long long *') [-Wformat]
  fprintf(stderr, "thread os id = 0x%llx\n", thread_os_id);
                                    ~~~~     ^~~~~~~~~~~~
1 warning and 1 error generated.
```

Add special Framework header search path for DriverKit.

The wrap/unwrap operations are applied to pointers after/before conversion to/from
raw addresses. They can be used to tag, untag, sign, or strip signing from
pointers. They currently default to 'rawPtr' (identity) on all platforms, but it
is expected that the default will be set based on the host architecture, e.g.
they would default to signing/stripping for arm64e.

This is the ORC runtime counterpart to f14cb494:

The __orc_rt::identity utility is intended to serve as a substitute for
c++20's std::identity until we can use the latter (when LLVM moves to c++20).

If constant shadown enabled we had false reports because
!isZeroValue() does not guaranty that the values is actually not zero.

Reviewed By: eugenis

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

This reverts commit 4b815eb4.