This commit ensures that we can include all libc++ headers with modules
enabled. It adds a test to ensure that this doesn't regress, which is
necessary because our modules CI job does not build in all Standard modes.

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

Patch to support "#pragma omp nothing"

Reviewed By: tianshilei1992

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

This is a support for " #pragma omp atomic compare fail ". It has Parser & AST support for now.

Reviewed By: tianshilei1992

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

We were incorrectly using VLMax instead of the passed VL.

Reviewed By: khchen, reames

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

CLOCK_REALTIME is POSIX defined and never available with MSVC, even without /permissive-.
The difference is that the template is never instantiated and the compiler ignores the undefined identifier.

Reviewed By: Meinersbur

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

We found untested code where negative frame indices were ostensibly
handled despite it being in a block guarded by !MFI.isFixedObjectIndex.

While the implementation of MachineFrameInfo::isFixedObjectIndex
suggests this is possible (i.e., if a frame index was more negative - less than the
number of fixed objects), I couldn't find any test in tree -- for any
target -- where a negative frame index wasn't also a fixed object
offset. I couldn't find a way of creating such a object with the
public MachineFrameInfo creation APIs. Even
MachineFrameInfo::getObjectIndexBegin starts counting at the negative
number of fixed objects, so such frame indices wouldn't be covered by
loops using the provided begin/end methods.

Given all this, an assert that any object encountered in the block is
non-negative seems reasonable.

Reviewed By: StephenFan, kito-cheng

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

Since this didn't make it into the v14 release - anyone requesting the
v14 ABI shouldn't get this GCC-compatible change that isn't backwards
compatible with v14 Clang.

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

More test coverage for the parts added by the One Ranges Proposal.

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

This reverts commit 62a9b36f.
Cause build failure on lldb incremental buildbot:
https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/43994/changes

According to the updates in CWG issue 2585
https://cplusplus.github.io/CWG/issues/2585.html, we shouldn't find an
allocation function with (size, p0, …, pn) in global scope.

Reviewed By: erichkeane

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

Reviewed By: spatel

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

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

Reviewed By: rafauler

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

This would be used in `BF::dumpGraph` to dump left-justified text.

Reviewed By: rafauler

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

Reviewed By: rafauler

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

The function is only used inside AArch64MCPlusBuilder class, there are no uses
of it as a BinaryFunction method.

Reviewed By: rafauler

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

This was inspired by D109336 which got reverted because we didn't want
the test to fail silently. This patch prints a more informative error
message when we fail to parse the simctl output while still failing the
test.

Differential revision: https://reviews.llvm.org/D126217

The LLDB website recommends using the CMake caches to build on macOS.
Although modules result in a faster build, this configuration tends to
break occasionally because it's specific to our platform. I don't expect
newcomers to be able to deal with those kind of breakages so don't
enable them by default.

5da7c040 introduced a regression in the NOLINT macro checking loop, replacing the
call to `getImmediateExpansionRange().getBegin()` with
`getImmediateMacroCallerLoc()`, which has similar but subtly different
behaviour.

The consequence is that NOLINTs cannot suppress diagnostics when they are
attached to a token that came from a macro **argument**, rather than elsewhere
in the macro expansion.

Revert to pre-patch behaviour and add test cases to cover this issue.

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

[DFSan] Add option to specify individual library files, and an option to exit with an error code if any library file was not found.

Reviewed By: vitalybuka

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

Fixes: #55410

Reviewed By: bixia

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

Reviewed By: nikic

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

Simple implementations of the functions pthread_mutex_init,
pthread_mutex_destroy, pthread_mutex_lock and pthread_mutex_unlock have
have also been added. Future patches will extend these functions to add
features required by the POSIX specification.

Reviewed By: lntue

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

This creates an entry with address=nullptr and flag=0x80.
When an 'omp_all_memory' entry is specified any other 'out' or
'inout' entries are not needed and are not passed to the runtime.

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

When the AVL value does not fit in 5 bits, the register in which this value is stored may be dead when we want to forward it. This patch ensure the kill flags on the register are cleared before forwarding.

Patch by: loralb
Differential Revision: https://reviews.llvm.org/D125971

Reviewed By: bixia

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

Instead of matching opcodes to know the format to emit, use an
enum value that we can get from the RISCVMatInt::Inst class.

Change the consumers to use fully covered switches so that we get
a compiler warning if a new kind is added. With the opcode checks
it was easier to forget to update one of the 3 consumers.

Reviewed By: reames

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

This patch teaches the VSETVLI insertion pass to perform a very limited form of partial redundancy elimination. The motivating example comes from the fixed length vectorization of a simple loop such as:

for (unsigned i = 0; i < a_len; i++)
    a[i] += b;

Without this change, the core vector loop and preheader is as follows:

.LBB0_3:                                # %vector.ph
	andi	a1, a6, -8
	addi	a4, a0, 16
	mv	a5, a1
.LBB0_4:                                # %vector.body
                                        # =>This Inner Loop Header: Depth=1
	addi	a3, a4, -16
	vsetivli	zero, 4, e32, m1, ta, mu
	vle32.v	v8, (a3)
	vle32.v	v9, (a4)
	vadd.vx	v8, v8, a2
	vadd.vx	v9, v9, a2
	vse32.v	v8, (a3)
	vse32.v	v9, (a4)
	addi	a5, a5, -8
	addi	a4, a4, 32
	bnez	a5, .LBB0_4

The key thing to note here is that, the execution of the vsetivli only needs to happen once. Since there's no tail folding happening here, the value of the vector configuration registers are invariant through the loop.

After this patch, we hoist the configuration into the preheader and perform it once.

.LBB0_3:                                # %vector.ph
	andi	a1, a6, -8
	vsetivli	zero, 4, e32, m1, ta, mu
	addi	a4, a0, 16
	mv	a5, a1
.LBB0_4:                                # %vector.body
                                        # =>This Inner Loop Header: Depth=1
	addi	a3, a4, -16
	vle32.v	v8, (a3)
	vle32.v	v9, (a4)
	vadd.vx	v8, v8, a2
	vadd.vx	v9, v9, a2
	vse32.v	v8, (a3)
	vse32.v	v9, (a4)
	addi	a5, a5, -8
	addi	a4, a4, 32
	bnez	a5, .LBB0_4

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

Fixes: #55165

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

Since the FIR operations are mostly structured, it is only the functions
that could contain multiple blocks inside an operation. This changes
with OpenMP since OpenMP regions can contain multiple blocks. For
unstructured code, the blocks are created in advance and belong to the
top-level function. This caused code in OpenMP region to be placed under
the function level.

In this fix, if the OpenMP region is unstructured then new blocks are
created inside it.

Note1: This is part of upstreaming from the fir-dev branch of
https://github.com/flang-compiler/f18-llvm-project. The code in this patch is a
subset of the changes in https://github.com/flang-compiler/f18-llvm-project/pull/1178.

Reviewed By: vdonaldson

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



Co-authored-by: Val Donaldson <vdonaldson@nvidia.com>
Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>
Co-authored-by: Valentin Clement <clementval@gmail.com>

This commit resolves a Linux kernel build failure that was revealed by
c35ca3a1. The patch introduces two new
intrinsics, which ultimately changes the intrinsic numbering of other PPC
intrinsics. This causes an issue introduced by
ff40fb07, as the patch checks for intrinsics
with particular values, but the addition of the fnabs/fnabss intrinsics updates
the original sqrt/sdiv intrinsic values.

B/O/Z input overflow is already caught, and real input overflow
is signalled as an IEEE arithmetic exception, but regular decimal
integer overflow was silent.

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

The derived type information table construction code had a
crash whose root cause was replacing an expression with one
of its operands -- the deletion of the LHS of that assignment
led to the RHS being invalidated before it could be read.
Fix by cloning the RHS.  Also update a TODO message to the
new "_todo_en_US" message class and add a comment about how
it should be resolved.

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

The scalar-default-character-expression that defines the interoperable
name of a function or subroutine (or interface) must have its names
resolved within the context of the subprogram, despite its appearance
on a function-stmt or a subroutine-stmt.  Failure to do so can lead
to bogus errors or to incorrect results.

The solution is to defer name resolution for function-stmt suffixes
(but not entry-stmt suffixes) and for subroutine-stmt language binding
specifications to EndSubprogram().  (Their resolution only need to be
deferred to the end of the specification part, but it's cleanest to
deal with it in EndSubprogram().)

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

Ignore `MemberLocToStruct` in environment comparison. As an ancillary data
structure, including it is redundant. We also can generate environments which
differ in their `MemberLocToStruct` but are otherwise equivalent.

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

User-defined derived type I/O subroutines need to be unique for
a given type and operation in any scope, but it is acceptable
to have more than one defined I/O subroutine so long as only one
of them is visible.

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