Attached patch fixes issues #63582 and #57718 when building my port to CYGWIN of llvm-project.
https://github.com/llvm/llvm-project/issues/63582
https://github.com/llvm/llvm-project/issues/57718

Reviewed By: mstorsjo

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

Default atomic ordering information is processed in the OpenMP dialect
to LLVM IR lowering stage at every spot where an operation can be
affected by it. The rest of clauses are stored globally in the
OpenMPIRBuilderConfig object before starting that lowering stage, so
that the OMPIRBuilder can conditionally modify code generation
depending on these. At the end of the process, the omp.requires
attribute is itself lowered into a global constructor that passes these
clauses as flags to the OpenMP runtime.

Depends on D147217, D147218 and D158278.

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

This patch implements the lowering of the OpenMP 'requires' directive
from Flang parse tree to MLIR attributes attached to the top-level
module.

Target-related 'requires' clauses are gathered and combined for each top-level
unit during semantics. Lastly, a single module-level `omp.requires` attribute
is attached to the MLIR module with that information at the end of the process.

The `atomic_default_mem_order` clause is not addressed by this patch, but
rather it will come as a separate patch and follow a different approach.

Depends on D147214, D150328, D150329 and D157983.

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

This patch updates the `OpenMPIRBuilderConfig` structure to hold all
available 'requires' clauses, and it replicates part of the code
generation for the 'requires' registration function from clang in the
`OMPIRBuilder`, to be used with flang.

Porting the rest of features of the clang implementation to the IRBuilder
and sharing it between clang and flang remains for a future patch, due to the
complexity of the logic selecting the attributes of the generated
registration function.

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

Before, we were silently letting the test pass, which masks test bugs;
for an
example, see https://github.com/llvm/llvm-project/pull/66195.

Minimize the headers included in header files to reduce the number of
files that need recompiled after a change.

2 of them were missing the ":" on the end.

Adding them broke the test so I had to add a new prefix just for the
warning runs only.

I manually checked the first RUNs and there is no warning emitted, as
expected.

This keeps it working after the gtest update in a866ce78

We apparently somehow had lowering for the STRICT nodes without any handling
for the normal operations. This makes sure we support the LRINT and LROUND
intrinsics for fp16 when +fullfp16 is not present.

Remove assertion violated by loop-like operations.

Signed-off-by: Victor Perez <victor.perez@codeplay.com>

[clang] Don't inherit dllimport/dllexport to exclude_from_explicit_instantiation members during explicit instantiation (#65961)

This is a continuation of https://reviews.llvm.org/D155713

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

Using:
black --exclude "third_party/" ./lldb/

This commit generalizes empty tensor elimination to operate on subset
ops. No new test cases are added because all current subset ops were
already supported previously. From this perspective, this change is NFC.

A new interface method (and a helper method) are added to
`SubsetInsertionOpInterface` to build the subset of the destination
tensor.

is_fpclass (fj, mask)
->
sltu (r0, and (movfr2gr.[sd] (fclass.[sd] fj), (to_fclass_mask mask)))

[1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#_fclass_sd

Reviewed By: wangleiat

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

This patch adds support for lowering vector.outerproduct to the ArmSME
MOPA intrinsic for the following types:

  vector<[8]xf16>,  vector<[8]xf16>  -> vector<[8]x[8]xf16>
  vector<[8]xbf16>, vector<[8]xbf16> -> vector<[8]x[8]xbf16>
  vector<[4]xf32>,  vector<[4]xf32>  -> vector<[4]x[4]xf32>
  vector<[2]xf64>,  vector<[2]xf64>  -> vector<[2]x[2]xf64>

The FP variants are lowered to FMOPA (non-widening) [1] and BFloat to
BFMOPA
(non-widening) [2].

Note at the ISA level these variants are implemented by different
architecture features, these are listed below:

  FMOPA (non-widening)
    * half-precision   - +sme2p1,+sme-f16f16
    * single-precision - +sme
    * double-precision - +sme-f64f64
  BFMOPA (non-widening)
    * half-precision   - +sme2p1,+b16b16

There's currently no way to target different features when lowering to
ArmSME. Integration tests are added for F32 and F64. We use QEMU to run
the integration test...

Since we have visitAPValue now, we might as well use it here.

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

When pushing a sub nsw 0, %x negation into an expression, try to
preserve the nsw flag for the cases where this is possible. Do this
by passing the flag through recursive Negator::negate() calls.

Proofs: https://alive2.llvm.org/ce/z/oRPNcY

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

Fixes #65877.

An assertion issue that arose when handling union member access with
virtual base class has been addressed. As pointed out by @zygoloid,
there is no need for further derived-to-base analysis in this instance,
so we can bail out upon encountering a virtual base class. Minor
refinement on the function name as we might not be handling a union.

Reported-By: ormris

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

Fixes SWDEV-403219

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.