[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

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.

Here, we are addressing task 2.1 from the plan, which involves renaming the vector reductions to align with the semantics of the corresponding LLVM intrinsics.

Reviewed By: dcaballe

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

…ocedure

When an previously unknown name appears as the target of an assignment
to a known procedure pointer, create an external symbol for it rather
than an implicitly-typed object symbol.

Some CFI_type_... type codes are synonyms; ensure that they are treated
as equivalent when validating inputs to CFI_... runtime routines.

Rationale:
This was actually just a pure "string based" test
with very little actual python usage. The output
sparse tensor was handled via the deprecated
convertFromMLIRSparseTensor method.

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.

This commit renames `maxf` and `minf` enumerators of `AtomicRMWKind`
to better reflect the current naming scheme and the goals of the RFC.

Pure intrinsic functions are acceptable in constant expressions so long
as their arguments are constant expressions. Allow them to appear in
subscripts in DATA statement variables.

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

This reverts commit c2fb112021529c635cccd8bb9d846b2c64fc291d, which
breaks:
```
lldb-api.commands/expression/diagnostics.TestExprDiagnostics.py
lldb-api.lang/objc/modules.TestObjCModules.py
lldb-api.lang/objc/modules-incomplete.TestIncompleteModules.py
lldb-api.lang/objc/modules-non-objc-target.TestObjCModulesNonObjCTarget.py
lldb-api.lang/objc/modules-objc-property.TestModulesObjCProperty.py
```

SparseVector->COO

The Windows MSVC builder complains: 'ImmMask' cannot be implicitly captured because no default capture mode has been
specified
When adding the explicit capture, Clang warns: Lambda capture 'ImmMask' is not required to be captured for this use

This seems to be a known implementation divergence. Using a default value capture should avoid the issue.

Using `extraClassOf` currently does not work with attribute or type
interfaces as the generated code calls `getInterfaceFor`, a private
method of `AttributeInterface` and `TypeInterface` respectively.

This PR fixes this by applying the same change that has been done to
`OpInterface` in the past: Make `getInterfaceFor` a protected member of
the class, allowing the generated code in subclasses to use it.

An attribute and type interface with `extraClassOf` have been added as
interfaces in the test dialect to ensure it compiles without errors.

We were catching automatic objects in modules and SAVE, but not in
COMMON blocks.

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

Value::ResolveValue calls Value::GetValueAsData as part of its
implementation. The latter can receive an optional Module pointer, which
is always null when called from the former. Allow threading in the
Module in Value::ResolveValue.

rdar://115021869

This patch reland 54c1a9b2, which
updates GoogleTest to v1.14.0. This patch fixes bots failures caused
by the early patch.

This fixes some unused variable and "comparison of integers of different
signs" warnings in the benchmarks.

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