The only possible kind of a conversion in initialization of a shared
pointer to an array is a qualification conversion (i.e., adding
cv-qualifiers). This patch adds tests for converting from `A[]` to
`const A[]` to the following functions:

```
template<class Y> explicit shared_ptr(Y* p);

template<class Y> shared_ptr(const shared_ptr<Y>& r);
template<class Y> shared_ptr(shared_ptr<Y>&& r);

template<class Y> shared_ptr& operator=(const shared_ptr<Y>& r);
template<class Y> shared_ptr& operator=(shared_ptr<Y>&& r);

template<class Y> void reset(Y* p);
template<class Y, class D> void reset(Y* p, D d);
template<class Y, class D, class A> void reset(Y* p, D d, A a);
```

Similar tests for converting functions that involve a `weak_ptr` should
be added once LWG issue [3001](https://cplusplus.github.io/LWG/issue3001)
is implemented.

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

Check for TARGET_CPU_ARM64 (ARM instructions for 64-bit mode) rather
than TARGET_CPU_ARM (instructions for 32-bit mode).

And fix a typo.

To fix failing build job.

To simplify suppressing warnings (for example, for
when multiple check aliases are enabled).

The globbing format reuses the same code as for
globbing when enabling checks, so the semantics
and behavior is identical.

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

The plugin currently uses a macro to check if this is a debug built
before assigning the debug kind variable to the device environment
struct. This is being deprecated because the new device runtime does not
maintain separate debug builds and should always be availible.

Reviewed By: tianshilei1992

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

Running tests for libunwind is a lot simpler than running tests for
libc++, so a simple Lit config file is sufficient. The benefit is that
we disentangle the libunwind test configuration from the libc++ and
libc++abi test configuration. The setup was too complicated, which led
to some bugs (notably we were running against the system libunwind on
Apple platforms).

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

Use FPU_REG macro to define dN registers, removing the wrong value_regs
while at it.  This is a piece-wise attempt of reconstructing D112066
with the goal of figuring out which part of the larger change breaks
the buildbot.

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

Summary:
Break out non-functional changes to the print-changed classes that are needed
for reuse with the DotCfg change printer in https://reviews.llvm.org/D87202.

Various changes to the change printers to facilitate reuse with the
upcoming DotCfg change printer. This includes changing several of
the classes and their support classes to being templates. Also,
some template parameter names were simplified to avoid confusion
with planned identifiers in the DotCfg change printer to come. A
virtual function in the class for comparing functions was changed
to a lambda. The virtual function same was replaced with calls to
operator==. The only intentional functional change was to add the exe name
as the first parameter to llvm::sys::ExecuteAndWait

Author: Jamie Schmeiser <schmeise@ca.ibm.com>
Reviewed By: aeubanks (Arthur Eubanks)
Differential Revision: https://reviews.llvm.org/D110737

Following on from an earlier patch that introduced support for -mtune
for AArch64 backends, this patch splits out the tuning features
from the processor features. This gives us the ability to enable
architectural feature set A for a given processor with "-mcpu=A"
and define the set of tuning features B with "-mtune=B".

It's quite difficult to write a test that proves we select the
right features according to the tuning attribute because most
of these relate to scheduling. I have created a test here:

  CodeGen/AArch64/misched-fusion-addr-tune.ll

that demonstrates the different scheduling choices based upon
the tuning.

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

The functions are moved above the parseClauses function as they
will be used inside it to parse `hint` clause

Reviewed By: clementval

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

This patch attempts to restrict the following P10 options:
```
-mprefixed
-mpcrel
-mpaired-vector-memops
```
To P10 only. This will prevent the use of these options on P9 and earlier.

The behaviour of this patch looks like the following on pre-P10:
```
$ clang -mcpu=pwr9 -mpaired-vector-memops test.c -o test
error: option '-mpaired-vector-memops' cannot be specified without '-mcpu=pwr10'
$ clang -mcpu=pwr9 -mprefixed test.c -o test
error: option '-mprefixed' cannot be specified without '-mcpu=pwr10'
$ clang -mcpu=pwr9 -mprefixed -mpcrel test.c -o test
error: option '-mpcrel' cannot be specified without '-mcpu=pwr10 -mprefixed'
$ clang -mcpu=pwr9 -mpcrel -mprefixed test.c -o test
error: option '-mpcrel' cannot be specified without '-mcpu=pwr10 -mprefixed'
$ clang -mcpu=pwr9 -mpcrel test.c -o test
error: option '-mpcrel' cannot be specified without '-mcpu=pwr10 -mprefixed'
```

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

This patch ensures that we always tune for a given CPU on AArch64
targets when the user specifies the "-mtune=xyz" flag. In the
AArch64Subtarget if the tune flag is unset we use the CPU value
instead.

I've updated the release notes here:

  llvm/docs/ReleaseNotes.rst

and added tests here:

  clang/test/Driver/aarch64-mtune.c

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

Mark LWG3420 as complete. Currently, the `cpp17_iterator` concept
checks that the type looks like an iterator first before checking if it
is copyable.

Reviewed By: ldionne, Quuxplusone, #libc

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

This is a piece-wise attempt of reconstructing D112066 with the goal
of figuring out which part of the larger change breaks the buildbot.

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

Inspired by D111968, provide a isNegatedPowerOf2() wrapper instead of obfuscating code with (-Value).isPowerOf2() patterns, which I'm sure are likely avenues for typos.....

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

This reverts commit 1c2c67b4.
Something's still wrong.

Allows us to use the small code model when we disable relocation
relaxation.

Reviewed By: eugenis

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

Fix incorrect values for value_regs, and incomplete values for
invalidate_regs in RegisterInfos_arm.  The value_regs entry needs
to list only one base (i.e. larger) register that needs to be read
to get the value for this register, while invalidate_regs needs to list
all other registers (including pseudo-register) whose values would
change when this register is written to.

While at it, introduce helper macros for the definitions.

7a8ba4ff fixed a similar problem
for ARM64.

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

Reviewed By: ezhulenev

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

Otherwise, the individual `check-cxx`, `check-cxxabi` and similar targets
will not know about `LLVM_LIT_ARGS`, and we'll end up running lit without
any argument.

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

Extract some code from the big ptach D111337. This patch
contains some utility functions from the FIRBuidler.

List of utility functions added:
- getRegion
- getModule
- getKindMap
- getRefType
- getVarLenSeqTy
- getRealType
- createNullConstant
- createRealConstant
- createRealZeroConstant
- createGlobal
- createGlobalConstant
- createStringLitOp
- getNamedFunction
- getNamedGlobal
- createFunction
- addNamedFunction
- createBool

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

Reviewed By: kiranchandramohan

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



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

Code reorganized in OpenMPDialect.cpp to have all functions corresponding to an operation together.

Added parseClauses function to avoid code duplication while parsing clauses in OpenMP operations. Also added printers and verifiers for clauses, which are being used for multiple operations.

Reviewed By: kiranchandramohan, peixin

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

Refactor ABIX86::AugmentRegisterInfo() and helper functions for better
readability.  This also fixes listing eax & co. as potential subregs
on 32-bit systems.

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

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

For example, if you have:
  void foo(int bar);
  foo(/*^
it should auto-complete to "bar=".

Because Sema callbacks for code completion in comments happen before we
have an AST we need to cheat in clangd by detecting completion on /*
before, moving cursor back by two characters, then running a simplified
verion of SignatureHelp to extract argument name(s) from possible
overloads.

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

The demangled name no longer contains the redundant name since D111715.

This reverts commit 5352ea4a.  It seems
to have broken the arm buildbot.

This is purely a performance patch: InstrRefBasedLDV used to use three
DenseMaps to store variable values, two for long term storage and one as a
working set. This patch eliminates the working set, and updates the long
term storage in place, thus avoiding two DenseMap comparisons and two
DenseMap assignments, which can be expensive.

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

We had two sets of build<flavour> methods, whose bodies were largely
identical. This makes any kind of modification in their vicinity
repetitive and error-prone.

Replace each set with a single method taking an optional debug_info
parameter.

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

This adds the `target dump typesystem'`command which dumps the TypeSystem of the
target itself (aka the 'scratch TypeSystem'). This is similar to `target modules
dump ast` which dumps the AST of lldb::Modules associated with a selected
target.

Unlike `target modules dump ast`, the new command is not a subcommand of `target
modules dump` as it's not touching the modules of a target at all. Also unlike
`target modules dump ast` I tried to keep the implementation language-neutral,
so this patch moves our Clang `Dump` to the `TypeSystem` interface so it will
also dump the state of any future/downstream scratch TypeSystems (e.g., Swift).
That's also why the command just refers to a 'typesystem' instead of an 'ast'
(which is only how Clang is necessarily modelling the internal TypeSystem
state).

The main motivation for this patch is that I need to write some tests that check
for duplicates in the ScratchTypeSystemClang of a target. There is currently no
way to check for this at the moment (beside measuring memory consumption of
course). It's probably also useful for debugging LLDB itself.

Reviewed By: labath

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

When printing names in lldb on windows these names contain the full type information while on linux only the name is contained.

This change introduces a flag in the Microsoft demangler to control if the type information should be included.
With the flag enabled demangled name contains only the qualified name, e.g:
without flag -> with flag
int (*array2d)[10] -> array2d
int (*abc::array2d)[10] -> abc::array2d
const int *x -> x

For globals there is a second inconsistency which is not yet addressed by this change. On linux globals (in global namespace) are prefixed with :: while on windows they are not.

Reviewed By: teemperor, rnk

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

`Target::GetScratchTypeSystems` returns the list of scratch TypeSystems. The
current implementation is iterating over all LanguageType values and retrieves
the respective TypeSystem for each LanguageType.

All C/C++/Obj-C LanguageTypes are however mapped to the same
ScratchTypeSystemClang instance, so the current implementation adds this single
TypeSystem instance several times to the list of TypeSystems (once for every
LanguageType that we support).

The only observable effect of this is that `SBTarget.FindTypes` for builtin
types currently queries the ScratchTypeSystemClang several times (and also adds
the same result several times).

Reviewed By: bulbazord, labath

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

The change is based on the proposal from the following discussion:
https://llvm.discourse.group/t/rfc-memreftype-affine-maps-list-vs-single-item/3968

* Introduce `MemRefLayoutAttr` interface to get `AffineMap` from an `Attribute`
  (`AffineMapAttr` implements this interface).
* Store layout as a single generic `MemRefLayoutAttr`.

This change removes the affine map composition feature and related API.
Actually, while the `MemRefType` itself supported it, almost none of the upstream
can work with more than 1 affine map in `MemRefType`.

The introduced `MemRefLayoutAttr` allows to re-implement this feature
in a more stable way - via separate attribute class.

Also the interface allows to use different layout representations rather than affine maps.
For example, the described "stride + offset" form, which is currently supported in ASM parser only,
can now be expressed as separate attribute.

Reviewed By: ftynse, bondhugula

Differential Revision: http...