This option outputs the location, encoded value and target of chained
fixups, using the same format as `otool -dyld_info`.

This initial implementation only supports the DYLD_CHAINED_PTR_64 and
DYLD_CHAINED_PTR_64_OFFSET pointer encodings, which are used in x86_64
and arm64 userspace binaries.

When Apple's effort to upstream their chained fixups code continues,
we'll replace this code with the then-upstreamed code. But we need
something in the meantime for testing ld64.lld's chained fixups code.

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

Identified with readability-redundant-declaration.

This patch replaces calls to greatestCommonDivisor with std::gcd where
both arguments are known to be of unsigned.  This means that
std::common_type_t of the two argument types should just be the wider
one of the two.

The use of std::clamp here is safe because the definition of
largestLDKind gurantees that 8 <= largestLDKind.

Replace the imperative pattern of the following kind
```
bool IsTrue = false;
for (Element : Range) {
  if (Condition(Element)) {
    IsTrue = true;
    break;
  }
}
```
with functional style `llvm::any_of`:
```
bool IsTrue = llvm::any_of(Range, [&](Element) {
  return Condition(Element);
});
```

Reviewed By: rafauler

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

We can safely use std::clamp here because the call to
report_size_overflow a few lines above guarantees MinSize <= MaxSize.

Identified with modernize-use-nullptr.

Identified with readability-redundant-control-flow.

Identified with readability-string-compare.

Identified with readability-qualified-auto.

This patch replaces calls to GreatestCommonDivisor64 with std::gcd
where both arguments are known to be of unsigned types no larger than
64 bits in size.

Fold memref.expand_shape and memref.collapse_shape ops into their
memref/affine load/store ops.

Reviewed By: bondhugula, nicolasvasilache

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

Currently the diagnostic is printed at the start of the assignment expression, This can be misleading.
Having the location for the diagnostic be the location of the assignment operator is much more intuitive.

Reviewed By: gribozavr2

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

In Parser::ParseUsingDeclaration(...) when we call ParseEnumSpecifier(...) it is
not calling SetTypeSpecError() on DS when it detects an error. That means that
DS is left set to TST_unspecified. When we then pass DS into
Sema::ActOnUsingEnumDeclaration(...) we hit an llvm_unreachable(...) since it
expects it to be one of three states TST_error, TST_enum or TST_typename.

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

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

Fixes #57373.

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

Add verification that VPHeaderPHIRecipes are only in header VPBBs. Also
adds missing checks for VPPointerInductionRecipe to
VPHeaderPHIRecipe::classof.

Split off from D119661.

Reviewed By: Ayal

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

This is needed to avoid passing flags that are supported by the compiler
but cause warnings to be emitted.

Reviewed By: ldionne, #libc

Spies: libcxx-commits

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

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