Evaluating `contiguous_iterator` on an iterator that satisfies all the
constraints except the `to_address` constraint and doesn't have
`operator->` defined results in a hard error. This is because
instantiating `to_address` ends up instantiating templates
dependent on the given type which might lead to a hard error even
in a SFINAE context.

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

Co-authored-by: Konstantin Varlamov <varconst@apple.com>

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

We will switch all UndefValue to PoisonValue in follow up patches.

Reviewed By: kito-cheng

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

This patch adds the ability to context-sensitively analyze method bodies, by moving `ThisPointeeLoc` from `DataflowAnalysisContext` to `Environment`, and adding code in `pushCall` to set it.

Reviewed By: ymandel, sgatev, xazax.hun

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

Reviewed By: ftynse

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

This should provide a more intuitive usage consistent with other tools.

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

This patch adds a `ReturnLoc` field to the `Environment`, serving a similar to the `ThisPointeeLoc` field in the `DataflowAnalysisContext`. It then uses that (along with a new `VisitReturnStmt` method in `TransferVisitor`) to handle non-`void`-returning functions in context-sensitive analysis.

Reviewed By: ymandel, sgatev

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

We would like to make the ACLE NEON and SVE intrinsics more useable by
gating them on the target, not by ifdef preprocessor macros. In order to
do this the types they use need to be available. This patches makes
__bf16 always available under AArch64 not just when the bf16
architecture feature is present. This bringing it in-line with GCC. In
subsequent patches the NEON bfloat16x8_t and SVE svbfloat16_t types
(along with bfloat16_t used in arm_sve.h) will be made unconditional
too.

The operations valid on the types are still very limited. They can be
used as a storage type, but the intrinsics used for convertions are
still behind an ifdef guard in arm_neon.h/arm_bf16.h.

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

Close #56885: WG14 N2630 added %b to fprintf/fscanf and recommended %B for
fprintf. This patch teaches -Wformat %b for the printf/scanf family of functions
and %B for the printf family of functions.

glibc 2.35 and latest Android bionic added %b/%B printf support. From
https://www.openwall.com/lists/libc-coord/2022/07/ no scanf support is available
yet.

Like GCC, we don't test library support.

GCC 12 -Wformat -pedantic emits a warning:

> warning: ISO C17 does not support the ‘%b’ gnu_printf format [-Wformat=]

The behavior is not ported.

Note: `freebsd_kernel_printf` uses %b differently.

Reviewed By: aaron.ballman, dim, enh

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

This connects the Symbolizer to the markup filter and enables the first
working end-to-end flow using the filter.

Reviewed By: peter.smith

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

Implements:
- LWG3432 Missing requirement for comparison_category

Implements part of:
- P1614R2 The Mothership has Landed

Reviewed By: #libc, ldionne, jloser, philnik

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

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

`transferBlock` and `computeBlockInputState` only read the
`BlockStates` vector for the predecessor block(s), and do not need to
mutate any of the contents. Only `runTypeErasedDataflowAnalysis`
writes into the `vector`, so simply down to an `ArrayRef`.

This reverts commit b692312c.
Breaks tests on Windows, see https://reviews.llvm.org/D130808#3699952

The `IR/AttributeTest.cpp` test fails to compile on Solaris:

  /vol/llvm/src/llvm-project/local/mlir/unittests/IR/AttributeTest.cpp:223:36: error: no matching function for call to 'allocate'
        AttrT::get(type, "resource", UnmanagedAsmResourceBlob::allocate(data));
                                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  /vol/llvm/src/llvm-project/local/mlir/unittests/IR/AttributeTest.cpp:237:3: note: in instantiation of function template specialization 'checkNativeAccess<mlir::detail::DenseResourceElementsAttrBase<int8_t>, char>' requested here
    checkNativeAccess<AttrT, T>(builder.getContext(), llvm::makeArrayRef(data),
    ^
  /vol/llvm/src/llvm-project/local/mlir/unittests/IR/AttributeTest.cpp:258:3: note: in instantiation of function template specialization 'checkNativeIntAccess<mlir::detail::DenseResourceElementsAttrBase<int8_t>, char>' requested here
    checkNativeIntAccess<DenseI8ResourceElementsAttr, int8_t>(builder, 8);
    ^
  /vol/llvm/src/llvm-project/local/mlir/include/mlir/IR/AsmState.h:221:3: note: candidate template ignored: requirement '!std::is_same<char, char>::value' was not satisfied [with T = char]
    allocate(ArrayRef<T> data, bool dataIsMutable = false) {
    ^
  /vol/llvm/src/llvm-project/local/mlir/include/mlir/IR/AsmState.h:214:26: note: candidate function not viable: requires at least 2 arguments, but 1 was provided
    static AsmResourceBlob allocate(ArrayRef<char> data, size_t align,
                           ^

I suspect this happens because `char` is `signed` by default on Solaris.

Tested on `amd64-pc-solaris2.11` and `sparcv9-sun-solaris2.11`.

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

This prepares patterns that sometimes are generated by the front-end
and would prohibit fusion of SDDMM flavored kernels.

Reviewed By: springerm

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

invalid IR. the fix was incomplete, this one is better and is believed
to be complete

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

This check is clearly incorrect, there's no way you should have an
eStateConnected event left on the queue if you've already launched
and hit a breakpoint in the program.  This check fails running remotely
on Darwin systems and on one remote Linux platform.  And if we do
find this failing somewhere, we should fix the bogus eStateConnected,
not the test.

Extracted from: https://reviews.llvm.org/D130268

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

[MLIR] Make the implementations for getMixedOffsets/Sizes/Strides independent of OffsetSizeAndStrideOpInterface

The functions are effectively independent of the interface already, however, they take it as an argument for no reason.
The current state complicates reuse outside of MLIR.

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

I found it in this commit: https://github.com/llvm/llvm-project/commit/a203acb9dd7227323d6161431225189d49917744

Reviewed By: Mordante

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

In D130807 we added the `skipprofile` attribute. This commit
changes the format so we can either `forbid` or `skip` profiling
functions by adding the `noprofile` or `skipprofile` attributes,
respectively. The behavior of the original format remains
unchanged.

Also, add the `skipprofile` attribute when using
`-fprofile-function-groups`.

Reviewed By: phosek

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

This reverts commit d959324e.

The target_include_directories in the clang-fuzzer CMake files
are set to PRIVATE instead of PUBLIC to prevent the clang buildbots
from breaking when symlinking clang into llvm.

The expression evaluator fuzzer itself has been modified to prevent a
bug that occurs when running it without a target.

As discussed in [0], this diff adds the `skipprofile` attribute to
prevent the function from being profiled while allowing profiled
functions to be inlined into it. The `noprofile` attribute remains
unchanged.

The `noprofile` attribute is used for functions where it is
dangerous to add instrumentation to while the `skipprofile` attribute is
used to reduce code size or performance overhead.

[0] https://discourse.llvm.org/t/why-does-the-noprofile-attribute-restrict-inlining/64108

Reviewed By: phosek

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

`SymbolTable::lookupSymbolIn` is an expensive operation and we do not want to do it twice

Reviewed By: ftynse

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

Adds the details for P2286 and its status.

Follow-up to D129097.

It is no longer a requirement that the `QualType` passed to to
`DataflowAnalysisContext::getStableStorageLocation()` is not null. A
null type pass as an argument is only applicable as the pointee type
of a `std::nullptr_t` pointer.

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

This is required for using clang-query in the CI

Reviewed By: Mordante, #libc

Spies: libcxx-commits, arichardson

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

This allows the construct to be shared between different backends. However, it
still remains illegal to use TypedPointerType in LLVM IR--the type is intended
to remain an auxiliary type, not a real LLVM type. So no support is provided for
LLVM-C, nor bitcode, nor LLVM assembly (besides the bare minimum needed to make
Type->dump() work properly).

Reviewed By: beanz, nikic, aeubanks

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

Previously cf.br cf.cond_br and cf.switch always lowered to their LLVM
equivalents. These ops are all ops that take in some values of given
types and jump to other blocks with argument lists of the same types. If
the types are not the same, a verification failure will later occur. This led
to confusions, as everything works when func->llvm and cf->llvm lowering
both occur because func->llvm updates the blocks and argument lists
while cf->llvm updates the branching ops. Without func->llvm though,
there will potentially be a type mismatch.

This change now only lowers the CF ops if they will later pass
verification. This is possible because the parent op and its blocks will
be updated before the contained branching ops, so they can test their
new operand types against the types of the blocks they jump to.

Another plan was to have func->llvm only update the entry block
signature and to allow cf->llvm to update all other blocks, but this had
2 problems:
1. This would create a FuncOp lowering in cf->llvm lowering which is
   awkward
2. This new pattern would only be applied if the containing FuncOp is
   marked invalid. This is infeasible with the shared LLVM type
   conversion/target infrastructure.

See previous discussions at
https://discourse.llvm.org/t/lowering-cf-to-llvm/63863 and
https://github.com/llvm/llvm-project/issues/55301

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

This patch adds a DenseI1ArrayAttr to support arrays of i1. Importantly,
the implementation is as a simple `ArrayRef<bool>` instead of using bit
compression, which was problematic in DenseElementsAttr.

Reviewed By: rriddle

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

Reviewed By: frasercrmck, craig.topper

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

This patch enhances clang's ability to check compile-time determinable
string literals as format strings, and can give FixIt hints at literals
(unlike gcc). Issue https://github.com/llvm/llvm-project/issues/55805


mentiond two compile-time string cases. And this patch partially fixes
one.

```
constexpr const char* foo() {
  return "%s %d";
}
int main() {
   printf(foo(), "abc", "def");
   return 0;
}
```

This patch enables clang check format string for this:

```
<source>:4:24: warning: format specifies type 'int' but the argument has type 'const char *' [-Wformat]
  printf(foo(), "abc", "def");
         ~~~~~         ^~~~~
<source>:2:42: note: format string is defined here
constexpr const char *foo() { return "%s %d"; }
                                         ^~
                                         %s
1 warning generated.
```

Reviewed By: aaron.ballman

Signed-off-by: YingChi Long <me@inclyc.cn>

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

The kernel was rejecting sizeof(struct GPR) as it was not a multiple of
8. Add a padding field to fix that.

One also wonders whether "cpsr" is right register name for aarch64.

This reverts commit 4e94f665.
See https://reviews.llvm.org/D129973#3698969 for reasoning.

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