> Dependent access checks.

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

We previously ignored dependent access checks to private members.
These are visible only to the `RequiresExprBodyExpr` (through `PerformDependentDiagnositcs`) and not to the individual requirements.

---

> Non-dependent access checks.
Fixes: https://github.com/llvm/llvm-project/issues/53334
Access to members in a non-dependent context would always yield an
invalid expression. When it appears in a requires-expression, then this
is a hard error as this would always result in a substitution failure.

https://eel.is/c++draft/expr.prim.req#general-note-1
> Note 1: If a requires-expression contains invalid types or expressions in its requirements, and it does not appear within the declaration of a templated entity, then the program is ill-formed. — end note]
> If the substitution of template arguments into a requirement would always result in a substitution failure, the program is ill-formed; no diagnostic required.

The main issue here is the delaying of the diagnostics.
Use a `ParsingDeclRAIIObject` creates a separate diagnostic pool for diagnositcs associated to the `RequiresExprBodyDecl`.
This is important because dependent diagnostics should not be leaked/delayed to higher scopes (Eg. inside a template function or in a trailing requires). These dependent diagnostics must be attached to the `DeclContext` of the parameters of `RequiresExpr` (which is the `RequiresExprBodyDecl` in this case).
Non dependent diagnostics, on the other hand, should not delayed and surfaced as hard errors.

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

The legwork for these was done by https://reviews.llvm.org/D138725. Here we're
just adding the arch names to the cmake files and linking them to
arm_min_SOURCES.

Reviewed By: MaskRay

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

Automatically generated by D130897. This fixed issue #58792.

Reviewed By: pengfei

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

This reverts commit 73712c87. It causes
a MemorySanitizer error in LLVM testsuite. See
the discussion on https://reviews.llvm.org/D137882 for details.

Rework the change to prevent build failures. NFCI.

The failing code was submitted as
cf7a8305 and reverted via
8bd65e53.

The rework in this new commit prevents failures like the following:

FAILED: tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Targets/RISCV.cpp.o
/usr/bin/c++  [bunch of non interesting stuff]  -c <path-to>/llvm-project/clang/lib/Basic/Targets/RISCV.cpp
In file included from <path-to>/llvm-project/clang/lib/Basic/Targets/RISCV.cpp:19:
<path-to>/llvm-project/llvm/include/llvm/TargetParser/RISCVTargetParser.h:29:10: fatal error: llvm/TargetParser/RISCVTargetParserDef.inc: No such file or directory
  29 | #include "llvm/TargetParser/RISCVTargetParserDef.inc"
     |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

These failures happen because the library LLVMTargetParser depends on
RISCVTargetParserTableGen, which is a tablegen target that generates
the list of CPUs in
llvm/TargetParser/RISCVTargetParserDef.inc. This *.inc file is
included by the public header file
llvm/TargetParser/RISCVTargetParser.h.

The header file llvm/TargetParser/RISCVTargetParser.h is also used in
components (clangDriver and clangBasic) that link into
LLVMTargetParser, but on some configurations such components might end
up being built before TargetParser is ready.

The fix is to make sure that clangDriver and clangBasic depend on the
tablegen target RISCVTargetParserTableGen, which generates the .inc
file whether or not LLVMTargetParser is ready.

WRT the original patch at https://reviews.llvm.org/D137517, this
commit is just adding RISCVTargetParserTableGen in the DEPENDS list of
clangDriver and clangBasic.

Since the pass is multithreaded, BC.Ctx must be protected. Otherwise we get crashes when processing.

Reviewed by: yota9

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

The section numbers got reshuffled around between v0.10 and [[ https://github.com/riscv/riscv-v-spec/blob/v1.0/v-spec.adoc |  v1.0 of the spec ]], this updates references in comments to refer to their version in v1.0.

Reviewed By: craig.topper

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

This reverts commit cf7a8305.

If we know that X & Pow2 != 0, then the bit at that position is
known one.

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

This can suppress compilation warning like `enumerated mismatch in conditional expression`.

See:
https://lab.llvm.org/staging/#/builders/236/builds/645/steps/6/logs/warnings__1_

LAI is cached during the LoopDistribute pass, and is later re-used during LoopVectorize. The problem is that LoopVectorize changes SCEV, and the cached LAI does not get updated. Hence, when re-using the cached LAI, it references an invalid SCEV.

Fixes #59319

Reviewed By: fhahn

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

Tests for D140851.

This patch removes the file `llvm/include/llvm/TargetParser/RISCVTargetParser.def` and replaces it with a tablegen-generated `.inc` file out of `llvm/lib/Target/RISCV/RISCV.td`.

The module system has been updated to make sure we can build clang/llvm with `-DLLVM_ENABLE_MODULES=On`

Reviewed By: craig.topper

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

Specifying an architecture revision should also add feature strings for
any dependent default extensions. Otherwise the new checks for
target-dependent features for acle intrinsics from D134353 and D132034
can fail.

This patch does that in setFeatureEnabled, similar to the addition of
dependent architecture revisions. +sve also needs to be added to armv9
architectures in the target parser, as it is implied by +sve2.

Fixes #59911

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

This follows the [[ https://discourse.llvm.org/t/rfc-promoting-the-loongarch-backend-from-experimental-to-official/67506/ | RFC ]].

Follow-on commits will add appropriate release notes changes etc.

Submit this now and in a minimal form so there is reasonable time before
16.0.0 is branched to resolve any issues arising from e.g. the backend
being exposed on different compiler/sanitizer setups.

The current builder for LoongArch is on the [[ https://lab.llvm.org/staging/#/builders/236 | staging area ]].

Reviewed By: jyknight, MaskRay, echristo, myhsu, tstellar, arsenm

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

Add implementation and loweirng for the extends_type_of
intrinsic.

The standard mentions this: otherwise if the dynamic type of A or MOLD is
extensible, the result is true if and only if the dynamic type of A is an
extension type of the dynamic type of MOLD. Which could be interpreted that
`extends_type_of(a, a)` could be false since a type is not an extension of
itself. Gfortran result for this is `true` so the same behavior is applied
here as well.

Depends on D141364

Reviewed By: jeanPerier, PeteSteinfeld

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

The test performed by same_type_as does not consider kind type
parameters. If an exact match is not found, the name of the
derived type is compared. The name in the runtime info does not include
the kind type parameters as it does in the mangled name.

Reviewed By: jeanPerier, PeteSteinfeld

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

Deallocation of intent(out) allocatable was done in D133348. This patch adds
an if guard when the deallocation is done through a runtime call. The runtime
is crashing if the box is not allocated. Call the runtime only if the box is
allocated. This is the case for derived type, polymorphic and unlimited
polymorphic entities.

Reviewed By: PeteSteinfeld

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

This is part of selecting `G_ATOMIC*` instructions. Select `isync`, `sync` and `lwsync` in GISel.

Reviewed By: arsenm

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

[LoongArch] Fixed llvm/test/CodeGen/LoongArch/intrinsic.ll test failure when EXPENSIV_CHECK is enabled [1].

Specifically:
```
*** Bad machine code: Using an undefined physical register ***
- function:    movgr2fcsr
- basic block: %bb.0 entry (0x1af5e60)
- instruction: MOVGR2FCSR $fcsr1, %0:gpr
- operand 0:   $fcsr1

*** Bad machine code: Using an undefined physical register ***
- function:    movfcsr2gr
- basic block: %bb.0 entry (0x133fae0)
- instruction: %0:gpr = MOVFCSR2GR $fcsr1
- operand 1:   $fcsr1
```

By building MachineInstructions, the state of the register is
clarified, and the error caused by using undefined physical registers
is fixed.

[1]: https://lab.llvm.org/buildbot/#/builders/16/builds/41677

The file hierarchy is reorganized into:

```
├── rvv-intrinsics-autogenerated
│   ├── non-policy
│   │   ├── non-overloaded
│   │   └── overloaded
│   └── policy
│       ├── non-overloaded
│       └── overloaded
└── rvv-intrinsics-handcrafted
```

Separating auto-generated test cases and hand-craft ones. The
auto-generated ones are basic API tests generated from the intrinsic
generator [0].

This re-organization allows direct copy-and-paste from the produced
outputs of the generator in future API changes, which is discussed
and needs to be implemented towards a v1.0 RVV intrinsic.

[0] https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/181

Reviewed By: craig.topper

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

Reviewed By: lntue

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

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

Reviewed By: nikic

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

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

This patch allows optimizeLoopExitWithUnknownExitCount to deal with
branches by conditions that are not immediately ICmp's, but aggregates
of ICmp's joined by arithmetic or logical AND/OR. Each ICmp is optimized
independently.

Differential Revision: https://reviews.llvm.org/D139832
Reviewed By: nikic

This has been obsoleted by C++ thread_local for a long time.
As far as I know, Xcode was the last supported toolchain to add
support for C++ thread_local in 2016.

As a precaution, use LLVM_THREAD_LOCAL which provides even greater
backwards compatibility, allowing this to function even pre-C++11
versions of GCC.

Reviewed By: nikic

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

Reviewed By: nikic

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

This patch properly recognizes the generic selection expression
introduced in C11, by adding an additional token type for the colons
present in such expressions.

Previously, they would be recognized as
"inline ASM colons" purely by the fact that those are the last thing
checked for.

I tried to avoid adding an addition token type, but since colons by
default like having spaces around them, I chose to add a new type so
that no space is added after the type selector.

Currently, no aspect of the formatting of these expressions in able to
be configured, as I'm not sure what could even be configured here.

One notable thing is that association list is always formatted as
either entirely on one line, if it can fit, or with line breaks
after every comma in the expression (also after the controlling expr.)

This visually makes them more similar to switch statements when long,
matching the behaviour of the selection expression, being that of a sort
of switch on types, but also allows for terseness when only selecting
for a few things.

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

Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay

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

D119599 added the ability to align compound assignments, right aligning
them in order to line up at the equals sign.
However, that patch didn't account for AlignTokens being called
recursively across scopes, which reset the right justification to be
false in any scope besides the top scope. This meant the compound
assignments were aligned, just not at the right place.
(No tests also ever introduced any scopes)

This patch makes sure to inherit the right justification value, just as
every other parameter is passed on.

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

Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay

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