Test a range of acceptable forms of co_broadcast calls, including
combinations of keyword and non-keyword actual arguments of
intrinsic and derived type.  Also test that several invalid forms
of co_sum call generate the correct error messages.

Reviewed By: ktras

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

In the case your framework bundles contain relocatable objects, and your
objects include LC_LINKER_OPTIONs for the framework, previously they
would not be deduplicated like they would have if they were static
archives. This was also the case if you passed `-framework` for the
framework as well.

Reviewed By: #lld-macho, thakis, oontvoo

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

EHTerminateScope is used to implement C++ noexcept semantics. Per C++
[except.terminate], it is implemented-defined whether no, some, or all
cleanups are run prior to terminatation.

Therefore, the code to run cleanups on the way towards termination is
unnecessary, and may be omitted.

After this change, we will still run some cleanups: any cleanups in a
function called from the noexcept function will continue to run, while
those in the noexcept function itself will not.

(Commit attempt 2: check InnermostEHScope != stable_end() before accessing it.)

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

This is completely unused upstream, and does not really have well defined semantics
on what this is supposed to do/how this fits into the ecosystem. Given that, as part of
splitting up the standard dialect it's best to just remove this behavior, instead of try
to awkwardly fit it somewhere upstream. Downstream users are encouraged to
define their own operations that clearly can define the semantics of this.

This also uncovered several lingering uses of ConstantOp that weren't
updated to use arith::ConstantOp, and worked during conversions because
the constant was removed/converted into something else before
verification.

See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for more discussion.

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

The Utils.cpp file in StandardOps essentially just contains utilities for interacting with arithmetic
operations, and at this point makes more sense as a utility file for the arithemtic dialect.

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

This is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion.

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

This is part of the larger effort to split the standard dialect. This will also allow for pruning some
additional dependencies on Standard (done in a followup).

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

Reviewed By: eugenis

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

This variable was added to `InstrProfWriter.cpp`  in D115693 by mistake and it isn't needed.

Reviewed By: kyulee

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

Summery:
  Fix a few typos in docs AMDGPUUsage.rst

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

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

Instead of using the (now deprecated) Projects build for libcxx, libcxxabi,
libunwind and compiler-rt, this patch uses the Bootstrapping build. This
implies that Clang will be built from scratch, and then the runtimes will
be built using that just-built Clang instead of the system compiler.
This is the correct way of assembling a toolchain, since we don't want
to ship runtimes that were built with a non-Clang compiler (or a
potentially older Clang).

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

Simplifies the code slightly.

Reviewed By: #lld-macho, thakis

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

As noted in D116804, we want to effectively invert that patch
for CPUs (intel) that don't break the false dependency on
sbb %eax, %eax

So we will likely want to create that here in the
X86DAGToDAGISel::Select() case for X86::SETCC_CARRY.

setjmp can return twice, but PostDominatorTree is unaware of this. as
such, it overestimates postdominance, leaving some cases where memory
does not get untagged on return. this causes false positives later in
the program execution.

this is a workaround for now, in the longer term PostDominatorTree
should be made aware of returns_twice, as this may cause problems
elsewhere.

See D118647 for equivalent fix to HWASan.

Reviewed By: eugenis

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

When a mode flag is modified (e.g., BLANK='ZERO') in an I/O data transfer
statement, ensure that the right set of mode flags is modified.
There's one set of mode flags that are captured by an OPEN
statement and maintained in the connection, and another that
is maintained in an I/O statement state record for local mutability.
Some I/O API routines were unconditionally modifying the persistent
set of flags.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

The verifier field is deprecated, and slated for removal.

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

Currently if an operation requires additional verification, it specifies an inline
code block (`let verifier = "blah"`). This is quite problematic for various reasons, e.g.
it requires defining C++ inside of Tablegen which is discouraged when possible, but mainly because
nearly all usages simply forward to a static function `static LogicalResult verify(SomeOp op)`.
This commit adds support for a `hasVerifier` bit field that specifies if an additional verifier
is needed, and when set to `1` declares a `LogicalResult verify()` method for operations to
override. For migration purposes, the existing behavior is untouched. Upstream usages will
be replaced in a followup to keep this patch focused on the hasVerifier implementation.

One main user facing change is that what was one `MyOp::verify` is now `MyOp::verifyInvariants`.
This better matches the name this method is called everywhere else, and also frees up `verify` for
the user defined additional verification. The `verify` function when generated now (for additional
verification) is private to the operation class, which should also help avoid accidental usages after
this switch.

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

- note that `split_view` has been renamed to `lazy_split_view`.
- fix formatting.

Also refactor tests for `indirectly_movable{,_storable}`.

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

this is so we can use it for aarch64 stack tagging.

Reviewed By: eugenis

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

Corrects the runtime implementation of I/O on files with
the access mode ACCESS='STREAM'.  This is a collection
of edge-case tweaks to ensure that the distinctions between
stream and direct/sequential files, unformatted or formatted,
are respected where appropriate.
Moves NextInField() from io-stmt.h to io-stmt.cpp --
it was getting too big to keep in a header.

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

This patch is a sticking-paster until D118774 solves the situation with
unique_ptrs. I'm certainly wishing I'd focused on that first X_X.

Note that most changes to `strings` and `views.span` from the One Ranges
Proposal are no longer applicable:
- free `begin` and `end` functions taking `basic_string_view` and `span`
  were removed by [P1870](http://wg21.link/p1870);
- `span::const_iterator` was removed by [LWG3320](https://cplusplus.github.io/LWG/lwg-defects.html#3320).

Reviewed By: #libc, Quuxplusone, ldionne

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

It was previously implemented by commit [45d048c2](https://reviews.llvm.org/rG45d048c20440989df2b4e1be1f9343225e7741ab).

Reviewed By: #libc, Quuxplusone, philnik, ldionne

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

This patch adds the support for `atomic compare` in `OMPIRBuilder`.

Reviewed By: jdoerfert

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