Fortran doesn't allow inaccessible procedure bindings to be
overridden, and this needs to apply to generic resolution.
When resolving a type-bound generic procedure from another
module, ensure only that the most extended override from its
module is used if it is PRIVATE, not a later apparent override
from another module.

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

This patch adds std::extents. extents is one of the core classes used by std::mdspan. It describes a multi-dimensional index space with a mix of compile time and runtime sizes. Furthermore, it is templated on the index type used to describe the multi-dimensional index space.

The class is designed to be highly optimizable in performance critical code sections, and is fully useable in constant expressions contexts.

Testing of this class tends to be somewhat combinatorical, due to the large number of possible corner cases involved in situations where we have both runtime and compile time extents. To add to this, the class is designed to be interoperable (in particular constructible) from arguments which only need to be convertible to the index_type, but are otherwise arbitrary user types. For a larger discussion on the design of this class refer to: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p0009r18.html



Co-authored-by: Damien L-G <dalg24@gmail.com>

Reviewed By:...

This patch does the bare minimum to import sanitizer_common_interceptors, but
without actually enabling any interceptors or meaningfully defining the
COMMON_INTERCEPT macros.

This will allow selectively enabling sanitizer_common interceptors (if the
appropriate macros are defined), as suggested by Vitaly in D149701.

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

Few hermetic tests are failing as they are running out of memory.

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

Incorrect error messages were issuing for symbol table entries
with the CONTIGUOUS attribute that didn't deserve them, like
host association symbols.  Put the CONTIGUOUS check into
CheckObjectEntity().

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

Establish a set of optional usage warnings, and enable some
only in "-pedantic" mode that, in our subjective experience
with application codes, seem to issue frequently without
indicating usage that really needs to be corrected.  By default,
with this patch the compiler should appear to be somewhat less
persnickety but not less informative.

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

There are not tests currently which use the main test framework but not
the `main` function from LibcTestMain.cpp. So, this change essentially
simplifies by merging the *TestMain libraries with the main test
libraries.

Reviewed By: michaelrj, jhuber6

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

This reverts commit ef1f27d6.

Adds missing test coverage for D150029.

Fixes #62679.

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

G_BSWAP was reverted -> added to this diff.

check plan: ninja check-llvm-codegen-x86

Future work: G_SUB and G_ZEXT need some modernization.

Reviewed By: arsenm

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

The AllocatorRingBuffer is allocated dynamically when Allocator is
initialized. This patch adds a corresponding deinitialization call in
unmapTestOnly, to avoid running out of virtual memory if the tests are run
a large number of times on memory-constrained platforms.

Reviewed By: Chia-hungDuan

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

The documentation should have been updated in 662548c8.
This updates it to be more accurate with the current design.

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

The motivation behind this refactor is to be able to use
DWARFAbbreviationDeclaration from LLDB. LLDB has its own implementation
of DWARFAbbreviationDeclaration that is very similar to LLVM's but it
has different semantics around error handling.

This patch modifies llvm::DWARFAbbreviationDeclaration::extract to
return an `llvm::Expected<ExtractState>` to differentiate between "I am
done extracting" and "An error has occured", something which the current
return type (bool) does not accurately capture.

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

This is in preparation for replacing the implementation
with a wrapper around computeKnownFPClass.

Try to use gt/lt compares with 0 instead of class.

In the CoarrayChecker, add checks for the constraints C1177 and
C1178 for event-wait-stmt. Add event-post-stmt to the check
for the constraints for sync-stat-list. Add a check for the
constraint C1176 on event-variable.

Reviewed By: PeteSteinfeld

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

Reviewed By: #libc, philnik, Mordante

Spies: Mordante, philnik, libcxx-commits

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

The source file is used to anchor the destructor of format_error. When
format is moved from experimental to stable this code would move to the
dylib. One issue with code in the dylib is that it can't be used in
constexpr context. There is a proposal to make format work during
constant evaluation

  P2758 Emitting messages at compile time

This paper has initially been received favourable by EWG. Therefore move
the code to the header. This also avoids possible availability issues on
Mac back deployment targets.

Note it is expected that format will no longer be experimental with the
next LLVM release.

Reviewed By: ldionne, #libc

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

This was requested in the review of D145807, but I had missed to
apply it before landing the patch.

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

Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent)
when compiling a file which has been set as having the language
C. This behaviour change only takes place if "cmake_minimum_required"
is set to 3.20 or newer, or if the policy CMP0119 is set to new.

Attempting to compile assembly files with "-x c" fails, however
this is workarounded in many cases, as OpenMP overrides this with
"-x assembler-with-cpp", however this is only added for non-Windows
targets.

Thus, after increasing cmake_minimum_required to 3.20, this breaks
compiling the GNU assembly for Windows targets; the GNU assembly is
used for ARM and AArch64 Windows targets when building with Clang.
This patch unbreaks that.

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

Reviewed in D148761; missed committing this before.

The build uses other mechanism to select the runtime.

Fixes #62719

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

Currently we use a template parameter called `InvertInbox` to invert the
inbox when we load it. This is more easily understood as a static check
on whether or not the process running it is the server. Inverting the
inbox makes the states 1 0 and 0 1 own the buffer, so it's easier to
simply say that the server own the buffer if in != out. Also clean up some of
the comments.

Reviewed By: JonChesterfield

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

The S_LPROC32_ID and S_GPROC32_ID CodeView Debug Symbols have a flags
field which LLVM has had the values for (in the ProcSymFlags enum) but
has never actually set.

These flags are used by Microsoft-internal tooling that leverages debug
information to do binary analysis.

Modified LLVM to set the correct flags:

- ProcSymFlags::HasOptimizedDebugInfo - always set, as this indicates that
debug info is present for optimized builds (if debug info is not emitted
for optimized builds, then LLVM won't emit a debug symbol at all).
- ProcSymFlags::IsNoReturn and ProcSymFlags::IsNoInline - set if the
function has the NoReturn or NoInline attributes respectively.
- ProcSymFlags::HasFP - set if the function requires a frame pointer (per
TargetFrameLowering::hasFP).

Per discussion in review, XFAIL'ing lldb test until someone working on
lldb has a chance to look at it.

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

Reviewed By: Peiming

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

https://bugs.chromium.org/p/chromium/issues/detail?id=1445676

This reverts commit 1030bd18.

https://bugs.chromium.org/p/chromium/issues/detail?id=1445676

This reverts commit 20a3c6e8.

https://bugs.chromium.org/p/chromium/issues/detail?id=1445676

This reverts commit 6d7b26ae.

This reverts commit 9725c740.

Change the lowering of SVE integer mla_x/mls_x and mad_x/msb_x
builtins to use dedicated undef (_u) intrinsics.

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

We were documenting that this was about recursive calls when it's
actually about arbitrary calls.

e.g., https://godbolt.org/z/en8sYd77E

Missed adding this check in previous commit so adding it through separate commit.

Reviewed By: raghavendhra

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

This patch adds two versions of `bcmp` optimized for architectures where unaligned accesses are either illegal or extremely slow.
It is currently enabled for RISCV 64 and RISCV 32 but it could be used for ARM 32 architectures as well.

Here is the before / after output of `libc.benchmarks.memory_functions.opt_host --benchmark_filter=BM_memcmp` on a quad core Linux starfive RISCV 64 board running at 1.5GHz.

Before
```
Run on (4 X 1500 MHz CPU s)
CPU Caches:
  L1 Instruction 32 KiB (x4)
  L1 Data 32 KiB (x4)
  L2 Unified 2048 KiB (x1)
----------------------------------------------------------------------
Benchmark            Time             CPU   Iterations UserCounters...
----------------------------------------------------------------------
BM_Memcmp/0/0        110 ns         66.4 ns     10404864 bytes_per_cycle=0.107646/s bytes_per_second=153.989M/s items_per_second=15.071M/s __llvm_libc::memcmp,memcmp Google A
BM_Memcmp/1/0        318 ns          211 ns      3026944 bytes_per_cycle=0.131539/s bytes_per_second=188.167M/s items_per_second=4.73691M/s __llvm_libc::memcmp,memcmp Google B
BM_Memcmp/2/0        204 ns          115 ns      6118400 bytes_per_cycle=0.121675/s bytes_per_second=174.058M/s items_per_second=8.70241M/s __llvm_libc::memcmp,memcmp Google D
BM_Memcmp/3/0        143 ns         99.6 ns      7013376 bytes_per_cycle=0.117974/s bytes_per_second=168.763M/s items_per_second=10.0437M/s __llvm_libc::memcmp,memcmp Google L
BM_Memcmp/4/0       81.3 ns         58.2 ns     11426816 bytes_per_cycle=0.101125/s bytes_per_second=144.661M/s items_per_second=17.1805M/s __llvm_libc::memcmp,memcmp Google M
BM_Memcmp/5/0        177 ns          118 ns      5952512 bytes_per_cycle=0.120612/s bytes_per_second=172.537M/s items_per_second=8.45549M/s __llvm_libc::memcmp,memcmp Google Q
BM_Memcmp/6/0        342 ns          220 ns      3483648 bytes_per_cycle=0.132004/s bytes_per_second=188.834M/s items_per_second=4.54739M/s __llvm_libc::memcmp,memcmp Google S
BM_Memcmp/7/0        208 ns          130 ns      5681152 bytes_per_cycle=0.12468/s bytes_per_second=178.356M/s items_per_second=7.6674M/s __llvm_libc::memcmp,memcmp Google U
BM_Memcmp/8/0        123 ns         79.1 ns      8387584 bytes_per_cycle=0.110593/s bytes_per_second=158.204M/s items_per_second=12.6439M/s __llvm_libc::memcmp,memcmp Google W
BM_Memcmp/9/0      20707 ns        10643 ns        67584 bytes_per_cycle=0.142401/s bytes_per_second=203.707M/s items_per_second=93.9559k/s __llvm_libc::memcmp,uniform 384 to 4096
```

After
```
BM_Memcmp/0/0       80.4 ns         55.8 ns     12648448 bytes_per_cycle=0.132703/s bytes_per_second=189.834M/s items_per_second=17.9256M/s __llvm_libc::memcmp,memcmp Google A
BM_Memcmp/1/0        140 ns         80.5 ns      8230912 bytes_per_cycle=0.337273/s bytes_per_second=482.474M/s items_per_second=12.4165M/s __llvm_libc::memcmp,memcmp Google B
BM_Memcmp/2/0        101 ns         66.4 ns     10571776 bytes_per_cycle=0.208539/s bytes_per_second=298.317M/s items_per_second=15.0687M/s __llvm_libc::memcmp,memcmp Google D
BM_Memcmp/3/0        118 ns         67.6 ns     10533888 bytes_per_cycle=0.176822/s bytes_per_second=252.946M/s items_per_second=14.7946M/s __llvm_libc::memcmp,memcmp Google L
BM_Memcmp/4/0        106 ns         53.0 ns     12722176 bytes_per_cycle=0.111141/s bytes_per_second=158.988M/s items_per_second=18.8591M/s __llvm_libc::memcmp,memcmp Google M
BM_Memcmp/5/0        141 ns         70.2 ns     10436608 bytes_per_cycle=0.26032/s bytes_per_second=372.39M/s items_per_second=14.2458M/s __llvm_libc::memcmp,memcmp Google Q
BM_Memcmp/6/0        144 ns         79.3 ns      8932352 bytes_per_cycle=0.353168/s bytes_per_second=505.211M/s items_per_second=12.612M/s __llvm_libc::memcmp,memcmp Google S
BM_Memcmp/7/0        123 ns         71.7 ns      9945088 bytes_per_cycle=0.22143/s bytes_per_second=316.758M/s items_per_second=13.9421M/s __llvm_libc::memcmp,memcmp Google U
BM_Memcmp/8/0       97.0 ns         56.2 ns     12509184 bytes_per_cycle=0.160526/s bytes_per_second=229.635M/s items_per_second=17.7784M/s __llvm_libc::memcmp,memcmp Google W
BM_Memcmp/9/0       1840 ns          989 ns       676864 bytes_per_cycle=1.4894/s bytes_per_second=2.08067G/s items_per_second=1010.92k/s __llvm_libc::memcmp,uniform 384 to 4096
```

glibc
```
BM_Memcmp/0/0       72.6 ns         51.7 ns     12963840 bytes_per_cycle=0.141261/s bytes_per_second=202.075M/s items_per_second=19.3246M/s glibc::memcmp,memcmp Google A
BM_Memcmp/1/0        118 ns         75.2 ns      9280512 bytes_per_cycle=0.354054/s bytes_per_second=506.478M/s items_per_second=13.3046M/s glibc::memcmp,memcmp Google B
BM_Memcmp/2/0        114 ns         62.9 ns     11152384 bytes_per_cycle=0.222675/s bytes_per_second=318.539M/s items_per_second=15.8943M/s glibc::memcmp,memcmp Google D
BM_Memcmp/3/0       84.0 ns         63.5 ns     11030528 bytes_per_cycle=0.186353/s bytes_per_second=266.581M/s items_per_second=15.7378M/s glibc::memcmp,memcmp Google L
BM_Memcmp/4/0       93.5 ns         51.2 ns     13462528 bytes_per_cycle=0.119215/s bytes_per_second=170.539M/s items_per_second=19.5384M/s glibc::memcmp,memcmp Google M
BM_Memcmp/5/0        123 ns         61.7 ns     11376640 bytes_per_cycle=0.225262/s bytes_per_second=322.239M/s items_per_second=16.1993M/s glibc::memcmp,memcmp Google Q
BM_Memcmp/6/0        122 ns         71.6 ns      9967616 bytes_per_cycle=0.380844/s bytes_per_second=544.802M/s items_per_second=13.9579M/s glibc::memcmp,memcmp Google S
BM_Memcmp/7/0        118 ns         65.6 ns     10555392 bytes_per_cycle=0.238677/s bytes_per_second=341.43M/s items_per_second=15.2334M/s glibc::memcmp,memcmp Google U
BM_Memcmp/8/0       90.4 ns         54.0 ns     12920832 bytes_per_cycle=0.161987/s bytes_per_second=231.724M/s items_per_second=18.5169M/s glibc::memcmp,memcmp Google W
BM_Memcmp/9/0       1045 ns          601 ns      1195008 bytes_per_cycle=2.53677/s bytes_per_second=3.54383G/s items_per_second=1.66423M/s glibc::memcmp,uniform 384 to 4096
```

Reviewed By: sivachandra

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

m_name_list is a std::unordered_set<std::string>, we can insert the
string directly instead of grabbing the c_str and creating yet another
one.

This helps fix a regression from D148309 where a shift + add was no longer
combined into a ssra. It looks for add's with v1i64 extract operands and
converts them to v1i64 adds. The other operand needs to be something that is
easily converted to a v1i64, in this case it currently just checks for a load.

Some of the code in performAddSubCombine has been cleaned up whilst I was here.

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

The right-hand sides of assignment statements are always expressions,
never variables.  When an assignment statement is converted into a call
to a defined assignment subroutine, and the actual argument being associated
with the second dummy argument is a variable, and the dummy argument does
not have the VALUE attribute, wrap it with parentheses so that lowering
will pass it by means of a temporary.

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

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