When performing a !nonnull load from uninitialized memory, we
should preserve the nonnull assume just like in all other cases.
We already do this correctly in the generic mem2reg code, but
don't handle this case when using the optimized single-block
implementation.

Make sure that the optimized implementation exhibits the same
behavior as the generic implementation.

C++20 deprecated ATOMIC_FLAG_INIT thinking it was deprecated in C when it
wasn't. It is expected to be undeprecated in C++23 as part of LWG3659
(https://wg21.link/LWG3659), which is currently Tentatively Ready.

This handles the case where the user includes <stdatomic.h> in C++ code in a
freestanding compile mode. The corollary libc++ changes are in
1544d1f9.

This shows a difference in behavior between the single block and
the multi block case.

commit: 51d3f421
failed due to missing python-pip om machine.
Now the ompd gdb-plugin code will be skipped with a warning
if pip is not available in the machine.

This commit adds SBSection.GetAlignment(), and SBSection.alignment as a python property to lldb.

Reviewed By: clayborg, JDevlieghere, labath

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

The patch didn't get proper attribution. Will recommit.

This reverts commit 4135abca.

This commit adds SBSection.GetAlignment(), and SBSection.alignment as a python property to lldb.

Reviewed By: clayborg, JDevlieghere, labath

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

These tests were using instructions that require feature predicates that
were not enabled.

- create the headers (but not include them from `<algorithm>`);
- define the niebloid and its member functions with the right signatures
  (as no-ops);
- make sure all the right headers are included that are required by each
  algorithm's signature;
- update `CMakeLists.txt` and the module map;
- create the test files with the appropriate synopses.

The synopsis in `<algorithm>` is deliberately not updated because that
could be taken as a readiness signal. The new headers aren't included
from `<algorithm>` for the same reason.

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

InlineAsm constraint string verification can fail for many reasons,
but used to always print a generic "invalid type for inline asm
constraint string" message -- which is especially confusing if
the actual error is unrelated to the type, e.g. a failure to parse
the constraint string.

Change the verify API to return an Error with a more specific
error message, and print that in the IR parser.

This member variable was removed a while ago in
44342735. It was previously used in
materialization code paths that have since been removed. Nowadays,
`m_object_pointer_type` gets set but not used anywhere.

This patch simply removes all remaining instances of it and any
supporting code.

**Testing**

* API tests pass

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

Various typos and formatting fixes that make the generated documentation
hard to follow.

This patch adds a formatter for libcxx's `std::unordered_map` iterators.
The implementation follows a similar appraoch to the `std::map` iterator
formatter. I was hesistant about coupling the two into a common
implementation since the libcxx layouts might change for one of the
the containers but not the other.

All `std::unordered_map` iterators are covered with this patch:
1. const/non-const key/value iterators
2. const/non-const bucket iterators

Note that, we currently don't have a formatter for `std::unordered_map`.
This patch doesn't change that, we merely add support for its iterators,
because that's what Xcode users requested. One can still see contents
of `std::unordered_map`, whereas with iterators it's less ergonomic.

**Testing**

* Added API test

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

support for OpenMP programs.

This is 5th of 6 patches started from https://reviews.llvm.org/D100181
This plugin code, when loaded in gdb, adds a few commands like
ompd icv, ompd bt, ompd parallel.
These commands create an interface for GDB to read the OpenMP
runtime through libompd.

Reviewed By: @dreachem
Differential Revision: https://reviews.llvm.org/D100185

This handle manipulation operation allows one to define a new handle that is
associated with a the same payload IR operations N times, where N can be driven
by the size of payload IR operation list associated with another handle. This
can be seen as a sort of broadcast that can be used to ensure the lists
associated with two handles have equal numbers of payload IR ops as expected by
many pairwise transform operations.

Introduce an additional "expensive" check that guards against consuming a
handle that is assocaited with the same payload IR operation more than once as
this is likely to lead to double-free or other undesired effects.

Depends On D129110

Reviewed By: nicolasvasilache

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

- checking that the algorithm supports predicates returning
  a non-boolean type that's implicitly convertible to `bool`;
- checking that predicates and/or projections are invoked using
  `std::invoke`.

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

Verify the LiveStacks analysis after a pass that claims to preserve it,
even if there are no further passes (apart from the verifier itself)
that would use the analysis.

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

This patch uses constFoldUnaryOpConditional to replace current folder in order to support constant dense.

Reviewed By: rriddle

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

visitInlineAsm() in SDAGBuilder was duplicating a lot of the code
in ParseConstraints(), in particular all the logic to determine the
operand value and constraint VT.

Rely on the data computed by ParseConstraints() instead, and update
its ConstraintVT implementation to match getCallOperandValEVT()
more precisely.

Currently any legal predicate types will be pattern-matched when
creating a PTEST instruction. This could be a problem in future since
PTEST always uses the .B specifier for the operand, but it is not
always guaranteed that the extra lanes of unpacked types (e.g. nxv4i1)
are zero. This patch ensures the operands of PTEST are type nxv16i1,
where the undef lanes are set to zero.

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

Reviewed By: myhsu

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

Since we now have +all feature for AArch64 disassembler, we can use it
in BOLT and allow it to disassemble all ARM instructions supported by LLVM.

Reviewed by: rafauler

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

Precise string layout has changed a lot recently, but a long of these
changes did not have any effect on the usages of its fields -- e.g.
introduction/removal of an anonymous struct or union does not change the
way one can access the field in C++. Our name-based variable lookup
rules (deliberately) copy the C++ semantics, which means these changes
would have been invisible to the them, if only we were using name-based
lookup.

This patch replaces the opaque child index accesses with name-based
lookups, which allows us to greatly simplify the data formatter code.
The formatter continues to support all the string layouts that it
previously supported.

It is unclear why the formatter was not using this approach from the
beginning. I would speculate that the original version was working
around some (now fixed) issue with anonymous members or base classes,
and the subsequent revisions stuck with that approach out of inertia.

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

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

As part of https://discourse.llvm.org/t/rfc-remove-most-constant-expressions/63179,
this removes support for the floating-point binop constant expressions
fadd, fsub, fmul, fdiv and frem.

As part of this change, the C APIs LLVMConstFAdd, LLVMConstFSub,
LLVMConstFMul, LLVMConstFDiv and LLVMConstFRem are removed.
The LLVMBuild APIs should be used instead.

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

This is still failing as endianness of binary blob external
resources is still not handled correctly.

https://reviews.llvm.org/D126446 added support for encoding
binary blobs in MLIR assembly.  To enable cross-architecture
compatibility, these need to be encoded in little-endian format.

This patch is a first step in that direction by reading and
writing the alignment tag that those blobs are prefixed by
in little-endian format.  This fixes assertion failures in
several test cases on big-endian platforms.

The actual content of the blob is not yet handled here.

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

When computing the base addresses of an array slice to make a
descriptor, codegen generated two LLVM GEPs. The first to compute
the address of the base character element, and a second one to
compute the substring base inside that element.
The previous code did not care about getting the result of the first
GEP right: it used the base array LLVM type as the result type.
This used to work when opaque pointer were not enabled (the actual GEP
result type was probably applied in some later pass). But with opaque
pointers, the second GEP ends-up computing an offset of len*<LLVM array
type> instead of len*<character width>. A previous attempt to fix the
issue was done in D129079, but it does not cover the cases where the
array slice contains subcomponents before the substring
(e.g: array(:)%char_field(5:10)).

This patch fix the issue by computing the actual GEP result type in
codegen. There is also enough knowledge now so that a single GEP can be
generated instead of two.

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

FirOpBuilder takes a fir::KindMapping reference. When the getKindMapping()
call is made inside the ctor call, the lifetime of this reference may
be as short as the ctor call (at least with when building flang in
release mode with clang 8). This can cause segfaults when later using
the FirOpBuilder.

Ensure the kindMap passed to the FirOpBuilder ctor is the same as the
FirOpBuilder.

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

MacroUnexpander applies the structural formatting of expanded lines into
UnwrappedLines to the corresponding unexpanded macro calls, resulting in
UnwrappedLines for the macro calls the user typed.

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

dot is currently miscompiled for booleans (uses add instead of or).

Reviewed By: bkramer

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

I thought I had already fixed all of these, but I guess I missed one.

As discussed on:
  https://discourse.llvm.org/t/build-llvm-release-bat-script-options/63146/6

Latest 7-zip versions (21.x) require administrator permissions
to create symbolic links.

Check if any of the following conditions is true:
- Version of 7-zip is 20.x or older
- Script is running with administrator permissions

Reviewed By: hans, thieta

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

According to @aaron.ballman this was marked Tentatively Ready as of 2022-07-07.
D129362 implemented the C counterpart.

Reviewed By: ldionne, #libc, Mordante

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

This can be enabled by using a `-re` suffix when defining the expected line,
e.g. `expected-error-re`. This support is similar to what clang provides in its "expected"
diagnostic framework(e.g. the `-re` is also the same). The regex definitions themselves are
similar to  FileCheck in that regex blocks are specified within `{{` `}}` blocks.

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

This patch replaces hasValue with has_value in an effort to deprecate
Optional<X>::hasValue.

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