The calculation of the source index was incorrect when a CSHIFT shift
count value is negative, for the implementation of CSHIFT for arrays
with rank >= 2.  (The vector CSHIFT is fine.)

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

One of the tests added in the recent floating point patch involves
string comparison against the debugger output; as DbgEng and LLDB have
different output, the test cannot pass against both of them, so disable
it on windows.

https://docs.microsoft.com/en-us/cpp/build/reference/external-external-headers-diagnostics?view=msvc-170

Reviewed By: hans

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

When an I/O statement is known to be in a recoverable error state,
it shouldn't cause a crash later in execution because it's not in
an expected non-erroneous processing state.  Add checking for the
ErroneousIoStatementState variant on paths that might otherwise
lead to runtime crashes.

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

This patch adds generation of sanitizer metadata attributes (which were
added in D126100) to the clang frontend.

We still currently generate the `llvm.asan.globals` that's consumed by
the IR pass, but the plan is to eventually migrate off of that onto
purely debuginfo and these IR attributes.

Reviewed By: vitalybuka, kstoimenov

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

A pair of tests had incorrect expectations set, one being an off-by-one
error and the other using decimal points in the expect that lldb omits.

Should fix the test failure introduced by D124561.

This reverts commit 1c84800c.

This was causing asan crash.

The little state machine in GetNextDataEdit() wasn't transitioning
properly from reading the imaginary part of the number back to the
real part for the next iteration of a repeated value.

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

See revision b8b7a9dc for prior art.

Reland of: 4463bd0f since the dependent
patch D126340 is also relanding.

The option mdefault-visibility-export-mapping is created to allow
mapping default visibility to an explicit shared library export
(e.g. dllexport). Exactly how and if this is manifested is target
dependent (since it depends on how they map dllexport in the IR).

Three values are provided for the option:

* none: the default and behavior without the option, no additional export linkage information is created.
* explicit: add the export for entities with explict default visibility from the source, including RTTI
* all: add the export for all entities with default visibility

This option is useful for targets which do not export symbols as part of
their usual default linkage behaviour (e.g. AIX), such targets
traditionally specified such information in external files (e.g. export
lists), but this mapping allows them to use the visibility information
typically used for this purpose on other (e.g. ELF) platforms.

This relands commit: 8c8a2679

with fixes for the compile time and assert problems that were reported
by:

* making shouldMapVisibilityToDLLExport inline and provide an early return
in the case where no mapping is in effect (aka non-AIX platforms)
* don't try to export RTTI types which we will give internal linkage to

Reviewed By: MaskRay

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

Track pending "asynchronous" I/O operation IDs so that WAIT statements can
report errors about bad ID numbers.

Lowering will need to extended to call GetAsynchronousId() for a READ or
WRITE statement with ID=n.

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

D120690 introduced `eBasicTypeChar8` but missed proper documentation order. This also introduces the missing bindings data on Swig, which should correspond with the documented information.

Reviewed By: labath

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

When nonadvancing output uses T/TL control edit descriptors to reposition
the record, don't reset the position to the furthest point written at
the end of the write.

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

Fix bolt-x86_64-wine-msvc builder:
https://lab.llvm.org/buildbot/#/builders/222/builds/1154

Reviewed By: maksfb

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

This reverts commit 8bbcb988.

Broke the UBSan bot. More details in https://reviews.llvm.org/D127376.

We cannot directly use the original result type; instead we need
to deduce it from the converted operand type. This addresses
invalid ops generated from converting single element vectors.

Reviewed By: ThomasRaoux

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

This avoids pulling in function converion patterns, which is not
part of what we want to test in ArithmeticToSPIRV. It also allows
using ConvertArithmeticToSPIRVPass as a standalone step.

Reviewed By: ThomasRaoux

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

This reverts commit b8f94597.

Broke the ASan buildbot. See https://reviews.llvm.org/D126781 for more
information.

This reverts commit 0ecbedc0.

Parent change broke the ASan buildbot. See
https://reviews.llvm.org/D126781 for more information.

Reviewed By: ThomasRaoux

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

Add TODO for KIND=2 so the user is notified correctly.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier, PeteSteinfeld

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



Co-authored-by: Peter Steinfeld <psteinfeld@nvidia.com>

[X86] combineEXTEND_VECTOR_INREG - don't attempt to shuffle combine ANY_EXTEND_VECTOR_INREG without SSE41

Without SSE41, ANY_EXTEND_VECTOR_INREG nodes are likely to be prematurely combined to a target shuffle preventing generic sign extension folds.

Fixes a number of sign-extend regressions in D127115.

This uses rotating reminder of division by 3 to select another
temp vgpr each next time in a sequence of several agpr copies.
Therefore, temp vgpr selection depends on the generated agpr
number. This number could change with any unrelated change to
the register definitions.

Stabilize the selection by using a real agpr number.

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

Add patterns to propagate vector distribution and remove dead
arguments. This handles propagation for several vector operations.

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

Loop variables of a worksharing loop and sequential loops in parallel
region are privatised by default. These variables are marked with
OmpPreDetermined. Skip explicit privatisation of these variables.

Note: This is part of upstreaming from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project.

Reviewed By: Leporacanthicus

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



Co-authored-by: Jean Perier <jperier@nvidia.com>
Co-authored-by: Mats Petersson <mats.petersson@arm.com>

All dialect targets in bazel have been named *Dialect and all dialect
targets in CMake have been named MLIR*Dialect.

This addresses the warning of unused template argument.

Reviewed By: ThomasRaoux, hanchung

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

All supported compilers have concepts support so use that in the C++20
functions in <bit>.

s/_LIBCPP_INLINE_VISIBILITY/_LIBCPP_HIDE_FROM_ABI/ as drive-by fix.

Reviewed By: #libc, ldionne

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

If we defer the mutation of the instruction, we can add the assert discussed in D126921.  Once we do that, the API becomes subject to revision - but let's do that in a separate change.

This simplifies the isel code by removing the manual load creation.
It also improves our ability to use 0 strided loads for vector splats.

There is an assumption here that Mask and ShiftedMask constants are
cheap enough that they don't become constant pool loads so that our
isel optimizations involving And still work. I believe those constants
are 3 instructions in the worst case.

The rv64zbp-intrinsic.ll changes is a regression caused by intrinsics
being expanded to RISCVISD also occuring during lowering. So the optimizations
were only happening during the last DAGCombine, which can't see through the
load. I believe we can fix this test by implementing
TargetLowering::getTargetConstantFromLoad for RISC-V or by adding the intrinsic
to computeKnownBitsForTargetNode to enable earlier DAG combine. Since Zbp is not
a ratified extension, I don't view these as blocking this patch.

Reviewed By: reames

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

This removes all "TODO: remove these headers" comments from our headers.

Note there seem to be more headers that can be removed, that will be
done in separate commits.

Reviewed By: #libc, ldionne

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

Based on the comments in [1] this should be fixed in GCC-11.

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37804

Reviewed By: #libc, ldionne

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

The compilers clang-11, clang-12, and apple-clang-12 are no longer
supported, so remove their annotations in the tests.

Reviewed By: #libc, philnik

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

Instead of trying to be clever and design our own locking primitive,
simply rely on the OS-provided implementation to do the right thing.

Indeed, manually yielding to the OS does not provide the necessary
information for it to make good prioritization decisions. For example,
if a thread with higher priority yields while waiting for a lock held
by a thread with lower priority but the system is contended, it is
possible for the thread with lower priority to not run until the higher
priority thread has yielded 16 times and goes for __libcpp_mutex_lock().
Once that happens, the OS can bump the priority of the thread that
currently holds the lock to unblock everyone. So instead, we might as
well give the system all the information from the start so it can make
appropriate decisions.

As a fly-by change, also increase the number of locks in the table.
The size increase is modest, but has the potential to half the amount
of contention on those locks.

rdar://93598606

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

Add TODO for half-precision for reduction.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier, PeteSteinfeld

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



Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

The pass was raising TODOs when a function both had a fir.boxproc<> argument
and a fir.type<> argument (even if the fir.type<> did not contain a
fir.boxproc itself).

Prevent the TODO from firing when a fir.type<> does not actually contain
a fir.boxproc. Add the location for the remaining TODO (it will be
needed when procedure pointer components are supported in lowering).

FYI, I actually tried to just implement the TODO, but I there is  a funny
issue. When creating the new fir::RecordType, since the name and context
are the same as the type being translated, fir::RecordType:get just
returns the existing type, and there is no way to change it (finalize()
does nothing since it is already finalized). So this will require to add
the ability to mutate the existing type, and I am not sure what are the
MLIR constraints here, so I escaped and left the TODO for that case.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: jeanPerier, PeteSteinfeld

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



Co-authored-by: Jean Perier <jperier@nvidia.com>