…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

The -fdebug-dump-all flag invokes runtime type information generation
even for a program with fatal semantic errors. This could cause a crash
on a failed CHECK(), since the type information table generator assumes
a correct program. Make it more resilient for a known fatal case. (But
if we hit many more of these, we should look into not generating the
runtime type information tables under this flag.)

I recently went to merge a PR that had a merge conflict:

    $ gh pr merge --squash --delete-branch
X Pull request #66003 is not mergeable: the merge commit cannot be
cleanly created.
To have the pull request merged after all the requirements have been
met, add the `--auto` flag.
    Run the following to resolve the merge conflicts locally:
gh pr checkout 66003 && git fetch origin main && git merge origin/main

This is how I resolved it; we should recommend this explicitly for
fellow contributors.

The two decimal float printing styles are similar, but different in how
they end. For simplicity of writing I initially gave them different
"write_last_block" functions. This patch unifies them into one function.

Reviewed By: sivachandra

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

Reviewed By: RKSimon

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

eq/ne are generally easier to reason about elsewhere.

ult -> ne: https://alive2.llvm.org/ce/z/5wxXGt
uge -> eq: https://alive2.llvm.org/ce/z/Dw6kqG

Reviewed By: nikic

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

Reviewed By: RKSimon

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

In the document on undefined behavior, I noted that writing down your
decisions is very important. This document contains all the information
for compile flags and undefined behavior for our printf.

Reviewed By: sivachandra

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

reland [InlineAsm] wrap ConstraintCode in enum class NFC (#66003)

This reverts commit ee643b70.

Fix up build failures in targets I missed in #66003

Kept as 3 commits for reviewers to see better what's changed. Will
squash when
merging.

- reland [InlineAsm] wrap ConstraintCode in enum class NFC (#66003)
- fix all the targets I missed in #66003
- fix off by one found by llvm/test/CodeGen/SystemZ/inline-asm-addr.ll