The builtin concurrency functionality for the workflows will cancel a
pending job if there is another job from the same workflow running. For
the pr-subscriber job, this means that if multiple labels are added at
the same time, then some of the pr-subscriber jobs will be cancelled and
the PR will not have all the necessary mentions.

This fixes the broken overlay builders.

See https://discourse.llvm.org/t/changes-to-pull-request-subscription-system/73296/

This follow an update made on OpenMP https://reviews.llvm.org/D129969
and was not possible on OpenACC until the unstructured construct was
supported.

This patch simplifies the color handling logic in Editline and
IOHandlerEditline:

 - Remove the m_color_prompts property from Editline and use the prompt
   ANSI prefix and suffix as the single source of truth. This avoids
   having to redraw the prompt unnecessarily, for example when colors
   are enabled but the prompt prefix and suffix are empty.

 - Rename m_color_prompts to just m_color in IOHandlerEditline and use
   it to ensure consistency between colored prompts and colored
   auto-suggestions. Some IOHandler explicitly turn off colors (such as
   IOHandlerConfirm) and it doesn't really make sense to have one or the
   other.

The name has been changed to adhere to the config option naming format.
The necessary build changes to use the new option have also been made.

Fix typos, add missing periods and reflow comments in the Editline
header.

Co-authored-by: lizhijin <lizhijin3@huawei.com>

Revert "Revert "Revert "[clang] Add experimental option to omit the RTTI component from the vtable when -fno-rtti is used"""

This reverts commit e16474ba.

This change is still causing a test failure on a bot: https://lab.llvm.org/buildbot/#/builders/139/builds/49666

Users often want to change the look of their prompt and currently the
only way to do that is by using ANSI escape codes in the prompt itself.
This is not only tedious, it also results in extra whitespace because
our Editline wrapper, when computing the cursor column, doesn't ignore
the invisible escape codes.

We already have various *-ansi-{prefix,suffix} settings that allow the
users to customize the color of auto-suggestions and progress events,
using mnemonics like ${ansi.fg.yellow}. This patch brings the same
mechanism to the prompt.

rdar://115390406

This patch adds support for labeled do loop after combined directive. It
relaxes the initial parser and canonicalize labeled do loop into the
OpenACCCombinedConstruct.

Make the `DoConstruct` in `OpenACCLoopConstruct` optional and move the
labeled do construct in in the canonicalization step.

For unstructured construct, the blocks are created in advance inside the
function body. This causes issues when the unstructured construct is
inside an OpenACC region operations. This patch adds the same fix than
OpenMP lowering and re-create the blocks inside the op region.

Initial OpenMP fix: 29f167ab

PExpect 4.6, when using 'utf-8' throws a TypeError when trying to write
to the log file:

  File "llvm-project/lldb/third_party/Python/module/pexpect-4.6/pexpect/spawnbase.py", line 126, in _log
    self.logfile.write(s)
  TypeError: a bytes-like object is required, not 'str'

This looks like a bug in PExpect to me. Since the log file is only used
for tracing, work around the issue by disabling the log file when
specifying an encoding. This should fix the Debian bot [1] which runs
the test with tracing enabled (-t).

[1] https://lab.llvm.org/buildbot/#/builders/68/builds/59955

[C++20] [Modules] [Serialization] Check input file contents with option ForceCheckCXX20ModulesInputFiles enabled

With overriden input files, e,g,. the compiler get the file from an
in-memroy buffer, the compiler can't get correct modified time information
to indicate whehter the input files are changed or not. Then, the
semantics of ForceCheckCXX20ModulesInputFiles are broken.

In this patch, if both ForceCheckCXX20ModulesInputFiles and
ValidateASTInputFilesContent and enabled, the compiler will still check the
hash value of the contents even if their modification time is the same.

Account for Unicode when computing the prompt column width. Previously,
the string length (i.e. number of bytes) rather than the width of the
Glyph was used to compute the cursor position. The result was that the
cursor would be offset to the right when using a prompt containing
Unicode.

There is case that R_PPC64_REL24 with non-zero addend. The assertion is incorrectly triggered in such situation.

Reviewed By: lhames

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

The instruction of ISD::FMINNUM/FMAXNUM should be legal if HasFPARMv8 &&
HasNEON.
For the combination of armv7+fp-armv8, armv7 imply the feature HasNEON
on, and fp-armv8 matchs the feature HasFPARMv8, so it is legal

Fixes https://github.com/llvm/llvm-project/issues/65820

The currently rule places .branch_lt after .data, which does not make
sense. The original contributor probably wanted to place .branch_lt
before .got/.toc, but failed to notice that .got/.toc are RELRO and
placed earlier.

Remove the special case so that .branch_lt is actually closer to .toc,
alleviating the distance issue.

According to @drodriguez's reminder in
https://github.com/apple/llvm-project/pull/7168#issuecomment-1710607896,
`memory` breaks the backport to the apple branch.

And this is irrelevant to that test. Delete to get better a test case.

This is a new API that has the same ownership quirk as the old API.

This is a tiny one-liner patch; changes in plists are entirely about
line numbers.

The associated function can be a nullptr if it is an indirect call.
This causes a crash in `CheckCallee` which always assumes the callee
is a valid pointer.

Fix #66904.

Revert "Revert "[clang] Add experimental option to omit the RTTI component from the vtable when -fno-rtti is used""

This attempts to reland 6385c1df but
with a fix for the test failure.

Revert "[clang] Add experimental option to omit the RTTI component from the vtable when -fno-rtti is used"

This reverts commit 6385c1df.

Reverting since this broke a windows builder:
https://lab.llvm.org/buildbot/#/builders/216/builds/27252.

…nters

When associating a function result pointer as an actual argument with a
dummy pointer that is assumed-rank, don't emit a bogus error.

This is information that the compiler already has, and should be exposed
so that the library doesn't need to reimplement the exact same
functionality.

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

Expression processing applies some straightforward rewriting of mixed
complex/real and complex/integer operations to avoid having to promote
the real/integer operand to complex and then perform a complex
operation; for example, (a,b)+x becomes (a+x,b) rather than (a,b)+(x,0).
But this can blow up the expression representation when the complex
operand cannot be duplicated cheaply. So apply this technique only to
complex operands that are appropriate to duplicate.

Fixes https://github.com/llvm/llvm-project/issues/65142.

MSVC allows users to pass structures with required alignments greater
than 4 to variadic functions. It does not pass them indirectly to
correctly align them. Instead, it passes them directly with the usual 4
byte stack alignment.

This change implements the same logic in clang on the passing side. The
receiving side (va_arg) never implemented any of this indirect logic, so
it doesn't need to be updated.

This issue pre-existed, but @aaron.ballman noticed it when we started
passing structs containing aligned fields indirectly in D152752.

For programs that don't use RTTI, the rtti component is just replaced with a
zero. This way, vtables that don't use RTTI can still cooperate with vtables
that use RTTI since offset calculations on the ABI level would still work.
However, if throughout your whole program you don't use RTTI at all (such as
the embedded case), then this is just an unused pointer-sized component that's
wasting space. This adds an experimental option for removing the RTTI component
from the vtable.

Some notes:
- This is only allowed when RTTI is disabled, so we don't have to worry about
  things like `typeid` or `dynamic_cast`.
- This is a "use at your own risk" since, similar to relative vtables, everything
  must be compiled with this since it's an ABI breakage. That is, a program compiled
  with this is not guaranteed to work with a program compiled without this, even
  if RTTI is disabled for both programs.

Note that this is a completely different ABI flavor orthogonal to the
relative-vtables ABI. That is, they can be enabled/disabled independently.

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

A RANK(*) case in a SELECT RANK construct selects the case of an
assumed-rank dummy argument whose effective actual argument is an
assumed-size array. In this case, the attributes of the selector are
those of a rank-1 assumed-size array, and the selector cannot be
allocatable or a pointer.

Ensure that the representation of a SELECT RANK construct's per-case
AssocEntityDetails can distinguish RANK(n), RANK(*), and RANK DEFAULT,
and clean up various code sites and tests where the distinctions matter.

Add UNSUPPORTED to pass tests on VE.  VE uses SjLj libunwind, so
_Unwind_Backtrace and _Unwind_ForcedUnwind are not implemented.

Reviewed By: MaskRay, #libc_abi, ldionne

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

Support VE in long double demangler.  This patch corrects
libcxxabi/test/test_demangle.pass.cpp on VE.

Reviewed By: MaskRay, #libc_abi, ldionne

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

The definitions of the ALLOCATED intrinsic in the intrinsics table did
not allow for an assumed-rank array.

Rationale:

This test was really fun to compare the MLIR sparsifier with TACO using
the PyTACO format. However, the underlying mechanism is rapidly growing
outdated with our recent developments. Rather than maintaining the old
code, we are moving toward the newer, better approaches. So if you are
sad this is gone, stay tuned, something better is coming!

This avoids making copies at the end of
`makeCommonInvocationForModuleBuild()` (in `ModuleDepCollector.cpp`).

This patch is part of a larger initiative aimed at fixing floating-point `max` and `min` operations in MLIR: https://discourse.llvm.org/t/rfc-fix-floating-point-max-and-min-operations-in-mlir/72671.

Within LLVM, there are no masked reduction counterparts for vector reductions such as `fmaximum` and `fminimum`.
More information can be found here: https://github.com/llvm/llvm-project/issues/64940#issuecomment-1690694156.

To address this issue in MLIR, where we need to generate appropriate lowerings for these cases, we employ regular non-masked intrinsics.
However, we modify the input vector using the `arith.select` operation to effectively deactivate undesired elements using a "neutral mask value".
The neutral mask value is the smallest possible value for the `fmaximum` reduction and the largest possible value for the `fminimum` reduction.

Depends on D158618

Reviewed By: dcaballe

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

This patch is part of a larger initiative aimed at fixing floating-point `max` and `min` operations in MLIR: https://discourse.llvm.org/t/rfc-fix-floating-point-max-and-min-operations-in-mlir/72671.

In line with the mentioned RFC, this patch  tackles tasks 2.3 and 2.4.
It adds LLVM conversions for the `maxf`/`minf` reductions to the non-NaN-propagating LLVM intrinsics.

Depends on D158618

Reviewed By: dcaballe

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