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

This started breaking in the CI because we bumped the Clang version
to 15, which requires adjusting the markup in the test suite.

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

VLMaxSentintel happens to be represented as -1 TargetConstant. A user
provided -1 would be an ISD::Constant. We shouldn't assume that they
are the same thing. I'm still not entirely convinced that we should be
treating -1 from the user as VLMAX.

Also fix one place that failed to use XLenVT for the VLMaxSentinel,
using MVT::i64 in code that only executes on RV32.

This reverts commit 842a2360 to fix the
bugs reported by users in https://reviews.llvm.org/D115955#3291538.

Assertion added in f50821cf confirms that the DT is indeed nonnull.
Change it to a reference instead of a pointer to make this explicit in
FusionCandidate.
Suggested in D118472.

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

After discussion in D116821 this was turned off in 74db5c8c,
14aaaa12 applied to limit the maximum memory consumption in rare
conditions, plus some performance patches.

Created to fix: https://github.com/llvm/llvm-project/issues/53537

Some intrinsics functions are considered commutative since they are performing operations like addition or multiplication. Some of these have extra parameters to provide extra information that are not part of the operation itself and are not commutative. This makes sure that if an instruction that is an intrinsic takes the non commutative path to handle this case.

Reviewer: paquette

Closes Issue #53537

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

This was using the ugly tablegenerated register enum names, which are
really hideous for register tuples on AMDGPU. Use the prettier names
which are recognized by the asm parser.

Warn on inline assembly clobbering reserved registers. It should also
warn on at least some reserved register defs, but that isn't happening
right now. If you have a def and re-use of a register we reserve, the
register coalescer will eliminate the intermediate virtual
register. When the reserved reg def is introduced later by the
backend, it will end up clobbering the value the register coalescer
assumed was live through the range.

There is also isInlineAsmReadOnlyReg, although I don't understand what
the distinction really is. It's called in SelectionDAGBuilder, long
before the set of reserved registers is frozen so I'm not sure how
that can possibly work reliably.

Unfortunately this is also using the ugly tablegenerated names for the
registers.

The lexer can attempt to lex a _Pragma and crash with an out of bounds string access when it's
lexing a _Pragma whose string token is an invalid buffer, e.g. when a module header file from which the macro
expansion for that token was deleted from the file system.

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

When a scope uses an explicit IMPORT statement to import a
symbol from the scope's host, it should not emit a bogus error
message later if that symbol is used in a specification construct.
The code that checks for imports being hidden by local declarations
was not allowing for the presence of host association (or USE)
indirection symbols in the local scope.  Fix by using GetUltimate()
before checking for the hidden symbol.

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

CMPLX was always rewritten as a complex constructor, but the second operand
of a complex constructor cannot be dynamically absent (i.e., a
disassociated pointer, an unallocated allocatable or an absent OPTIONAL
dummy argument), while the second argument of CMPLX can be dynamically
absent.

To avoid having to generate branches in complex constructor lowering
when Y is a pointer, keep the distinction between CMPLX and a complex
constructor when Y is a pointer, an allocatable, or an OPTIONAL entity.

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

When constructing the representation for a component reference
to an inherited component, expression semantics make the parent
component references explicit in the DataRef; e.g., base%component
becomes base%parent%grandparent%component if component was
inheritance-associated through two levels.  But expression semantics
was inserting references to the symbol table entries for the
intermediate types, not the symbols for the parent components in
the extended types.  (We didn't notice the distinction until
recently because both symbols have the same name; this only
affects lowering.)  Find and use the right symbols.

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

The Standard name for this exposition-only concept is _can-reference_.

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