Summary:
So far it seems like the only test affected by this change is the one I
recently added for R_MIPS_JALR relocations since the other test cases that
use this function early (unknown-relocation-*) do not have a valid input
section for the relocation offset.

Reviewers: ruiu, grimar, MaskRay, espindola

Reviewed By: ruiu, MaskRay

Subscribers: emaste, sdardis, jrtc27, atanasyan, llvm-commits

Tags: #llvm

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

This reverts commit 9468e333.

There's a test that doesn't like this change. The RDA analysis
gets invalided by changes in the block, which is not taken into
account. Revert while I work on a fix for this.

Summary:
Better use of multiclass is used, and this helped find some existing
bugs in the predicated VMULL* intrinsics, which are now fixed.

The refactored VMULL[TB]Q_(INT|POLY)_M() intrinsics were discovered
to have an argument ("inactive") with incorrect type, and this required
a fix that is included in this whole patch. The argument "inactive"
should have been the same width (per vector element) as the return
type of the intrinsic, but was not in the case where the return type
was double the element width of the input types.

To assist in testing the multiclassing , and to thwart further gremlins,
the unit tests are improved in scope.

The *.ll tests are all generated by a small bit of throw-away scripting
from the corresponding *.c tests, and as such the diffs are large and
nasty. Look at the file rather than the diff.

Reviewers: dmgreen, miyuki, ostannard, simon_tatham

Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

Summary:
A lot of our tests copied the setUp code from our TestSampleTest.py:

```
    def setUp(self):
        # Call super's setUp().
        TestBase.setUp(self)
```

This code does nothing unless we actually do any setUp work in there, so let's remove all these method definitions.

Reviewers: labath, JDevlieghere

Reviewed By: labath

Subscribers: lldb-commits

Tags: #lldb

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

[lldb][NFC] Remove 'from __future__ import print_function' from all tests that don't actually call 'print()'

Summary:
A lot of tests do this trick but the vast majority of them don't even call `print()`.

Most of this patch was generated by a script that just looks at all the files and deletes the line if there is no `print (` or `print(` anywhere else in the file.
I checked the remaining tests manually and deleted the import if we never call print (but instead do stuff like `expr print(...)` and similar false-positives).
I also corrected the additional empty lines after the import in the files that I manually edited.

Reviewers: JDevlieghere, labath, jfb

Reviewed By: labath

Subscribers: dexonsmith, wuzish, nemanjai, kbarton, christof, arphaman, abidh, lldb-commits

Tags: #lldb

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

The target feature matrix in the code generator documentation is
outdated. This PR fixes some entries for PowerPC and SystemZ.

Both have:
- assembly parser
- disassembler
- .o file writing

Reviewers: uweigand

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

Summary:
LLDB associates additional information with Types and Declarations which it calls ClangASTMetadata.
ClangASTMetadata is stored by the ClangASTSourceCommon which is implemented by having a large map of
`void *` keys to associated `ClangASTMetadata` values. To make this whole mechanism even unsafer
we also decided to use `clang::Decl *` as one of pointers we throw in there (beside `clang::Type *`).

The Decl class hierarchy uses multiple inheritance which means that not all pointers have the
same address when they are implicitly converted to pointers of their parent classes. For example
`clang::Decl *` and `clang::DeclContext *` won't end up being the same address when they
are implicitly converted from one of the many Decl-subclasses that inherit from both.

As we use the addresses as the keys in our Metadata map, this means that any implicit type
conversions to parent classes (or anything else that changes the addresses) will break our metadata tracking
in obscure ways.

Just to illustrate how broken this whole mechanism currently is:
```lang=cpp
  // m_ast is our ClangASTContext. Let's double check that from GetTranslationUnitDecl
  // in ClangASTContext and ASTContext return the same thing (one method just calls the other).
  assert(m_ast->GetTranslationUnitDecl() == m_ast->getASTContext()->getTranslationUnitDecl());
  // Ok, both methods have the same TU*. Let's store metadata with the result of one method call.
  m_ast->SetMetadataAsUserID(m_ast->GetTranslationUnitDecl(), 1234U);
  // Retrieve the same Metadata for the TU by using the TU* from the other method... which fails?
  EXPECT_EQ(m_ast->GetMetadata(m_ast->getASTContext()->getTranslationUnitDecl())->GetUserID(), 1234U);
  // Turns out that getTranslationUnitDecl one time returns a TranslationUnitDecl* but the other time
  // we return one of the parent classes of TranslationUnitDecl (DeclContext).
```

This patch splits up the `void *` API into two where one does the `clang::Type *` tracking and one the `clang::Decl *` mapping.
Type and Decl are disjoint class hierarchies so there is no implicit conversion possible that could influence
the address values.

I had to change the storing of `clang::QualType` opaque pointers to their `clang::Type *` equivalents as
opaque pointers are already `void *` pointers to begin with. We don't seem to ever set any qualifier in any of these
QualTypes to this conversion should be NFC.

Reviewers: labath, shafik, aprantl

Reviewed By: labath

Subscribers: JDevlieghere, lldb-commits

Tags: #lldb

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

Updated pred_load patterns added to AArch64SVEInstrInfo.td by this patch
to use reg + imm non-temporal loads to fix previous test failures.

Original commit message:

Adds the following intrinsics:
  - llvm.aarch64.sve.ldnt1
  - llvm.aarch64.sve.stnt1

This patch creates masked loads and stores with the
MONonTemporal flag set when used with the intrinsics above.

Summary:
This is a quickfix for PR44275. An assertion that checks that the
DIExpression is valid failed due to attempting to create an entry value
for an indirect parameter. This started appearing after D69028, as the
indirect parameter started being represented using an DW_OP_deref,
rather than with the DBG_VALUE's second operand, meaning that the
isIndirectDebugValue() check in LiveDebugValues did not exclude such
parameters. A DIExpression that has an entry value operation can
currently not have any other operation, leading to the failed isValid()
check.

This patch simply makes us stop considering emitting entry values
for such parameters. To support such cases I think we at least need
to do the following changes:

 * In DIExpression::isValid(): Remove the limitation that a
   DW_OP_LLVM_entry_value operation can be the only operation in a
   DIExpression.

 * In LiveDebugValues::emitEntryValues(): Create an entry value of size
   1, so that it only wraps the register operand, and not the whole
   pre-existing expression (the DW_OP_deref).

 * In LiveDebugValues::removeEntryValue(): Check that the new debug
   value has the same debug expression as the original, rather than
   checking that the debug expression is empty.

 * In DwarfExpression::addMachineRegExpression(): Modify the logic so
   that a DW_OP_reg* expression is emitted for the entry value.
   That is how GCC emits entry values for indirect parameters. That will
   currently not happen to due the DW_OP_deref causing the
   !HasComplexExpression to fail. The LocationKind needs to be changed
   also, rather than always emitting a DW_OP_stack_value for entry values.

There are probably more things I have missed, but that could hopefully
be a good starting point for emitting such entry values.

Reviewers: djtodoro, aprantl, jmorse, vsk

Reviewed By: aprantl, vsk

Subscribers: hiraditya, llvm-commits

Tags: #debug-info, #llvm

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

At least one lldb bot still uses this cmake variable instead of
LLDB_ENABLE_CURSES. Add code to set the default value of the "enable"
variable based on the old value of the "disable" setting.

This should bring those bots back up, until we can update the master to
use the new setting.

Reviewers: ilya-biryukov, hokein

Subscribers: MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

Summary: Follow-up to the patch D71248

Reviewers: sammccall

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

Summary:
Initial patch for new rendering structs in clangd.

Splitting implementation into smaller chunks, for a full view of the API see D71063.

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

Reviewers: sammccall

Currently we have the `Flags` property that allows to
set flags for a section. The problem is that it does not
allow us to set an arbitrary value, because of bit fields
validation under the hood. An arbitrary values can be used
to test specific broken cases.

We probably do not want to relax the validation, so this
patch adds a `ShSize` property that allows to
override the `sh_size`. It is inline with others `Sh*` properties
we have already.

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

I've noticed that when we have all regular flags set, we print "WAEXMSILoGTx"
instead of "WAXMSILOGTCE" printed by GNU readelf.

It happens because:
1) We print SHF_EXCLUDE at the wrong place.
2) We do not recognize SHF_COMPRESSED, we print "x" instead of "C".
3) We print "o" instead of "O" for SHF_OS_NONCONFORMING.

This patch fixes differences and adds test cases.

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

[LegalizeTypes] Remove unnecessary if before calling ReplaceValueWith on the chain in SoftenFloatRes_LOAD.

I believe this is a leftover from when fp128 was softened to fp128
on X86-64. In that case type legalization must have been able to
create a load that was the same as N which would make this
replacement fail or assert. Since we no longer do that, this
check should be unneeded.

This is a rebase of the change over D70376, which fixes an LVI cache
invalidation issue that also affected this patch.

-----

Related to D69686. As noted there, LVI currently behaves differently
for integer and pointer values: For integers, the block value is always
valid inside the basic block, while for pointers it is only valid at
the end of the basic block. I believe the integer behavior is the
correct one, and CVP relies on it via its getConstantRange() uses.

The reason for the special pointer behavior is that LVI checks whether
a pointer is dereferenced in a given basic block and marks it as
non-null in that case. Of course, this information is valid only after
the dereferencing instruction, or in conservative approximation,
at the end of the block.

This patch changes the treatment of dereferencability: Instead of
including it inside the block value, we instead treat it as something
similar to an assume (it essentially is a non-nullness assume) and
incorporate this information in intersectAssumeOrGuardBlockValueConstantRange()
if the context instruction is the terminator of the basic block.
This happens either when determining an edge-value internally in LVI,
or when a terminator was explicitly passed to getValueAt(). The latter
case makes this change not fully NFC, because we can now fold
terminator icmps based on the dereferencability information in the
same block. This is the reason why I changed one JumpThreading test
(it would optimize the condition away without the change).

Of course, we do not want to recompute dereferencability on each
intersectAssume call, so we need a new cache for this. The
dereferencability analysis requires walking the entire basic block
and computing underlying objects of all memory operands. This was
previously done separately for each queried pointer value. In the
new implementation (both because this makes the caching simpler,
and because it is faster), I instead only walk the full BB once and
cache all the dereferenced pointers. So the traversal is now performed
only once per BB, instead of once per queried pointer value.

I think the overall model now makes more sense than before, and there
will be no more pitfalls due to differing integer/pointer behavior.

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

This patch removes xpass decorator from tests which were failing due to
pr44037.

pr44037 was fixed by rev 6ce1a897

Add a description about the compression level of the debug info.

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

Reviewers: krasimir

Reviewed By: krasimir

Subscribers: Jim, cfe-commits

Tags: #clang

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

[libcxx] [test] Calling min and max on an empty valarray is UB.

libcxx/test/std/numerics/numarray/template.valarray/valarray.members/min.pass.cpp
libcxx/test/std/numerics/numarray/template.valarray/valarray.members/max.pass.cpp

The calls `v1.min();` and `v1.max();` were emitting nodiscard warnings
with MSVC's STL. Upon closer inspection, these calls were triggering
undefined behavior. N4842 [valarray.members] says:

"T min() const;
8 Preconditions: size() > 0 is true.
T max() const;
10 Preconditions: size() > 0 is true."

As these tests already provide coverage for non-empty valarrays
(immediately above), I've simply deleted the code for empty valarrays.

[libcxx] [test] Add macros to msvc_stdlib_force_include.h (NFC).

libcxx/test/support/msvc_stdlib_force_include.h

These macros are being used by:
libcxx/test/std/utilities/meta/meta.trans/meta.trans.other/result_of11.pass.cpp
Defining them to nothing allows that test to pass.

[libcxx] [test] Silence MSVC warning C5063 for is_constant_evaluated (NFC).

libcxx/test/std/utilities/meta/meta.const.eval/is_constant_evaluated.pass.cpp

This test is intentionally writing code that MSVC intentionally warns
about, so the warning should be silenced.

Additionally, comment an endif for clarity.

[libcxx] [test] Silence MSVC warning C4127 (NFC).

libcxx/test/support/charconv_test_helpers.h

MSVC avoids emitting this warning when it sees a single constexpr value
being tested, but this condition is a mix of compile-time and run-time.
Using push-disable-pop is the least intrusive way to silence this.

[libcxx] [test] Silence MSVC truncation warning (NFC).

libcxx/test/std/containers/sequences/vector/vector.cons/construct_iter_iter.pass.cpp

This test is intentionally truncating float to int, which MSVC
intentionally warns about, so push-disable-pop is necessary.

[libcxx] [test] Avoid truncation warnings in erase_if tests (NFC).

libcxx/test/std/containers/associative/map/map.erasure/erase_if.pass.cpp
libcxx/test/std/containers/associative/multimap/multimap.erasure/erase_if.pass.cpp
libcxx/test/std/containers/unord/unord.map/erase_if.pass.cpp
libcxx/test/std/containers/unord/unord.multimap/erase_if.pass.cpp

These tests use maps with `short` keys and values, emitting MSVC
truncation warnings from `int`. Adding `static_cast` to `key_type`
and `mapped_type` avoids these warnings.

As these tests require C++20 mode (or newer), for brevity I've changed
the multimap tests to use emplace to initialize the test data.
This has no effect on the erase_if testing.

Summary: Coaleascer should be coalescer.

Reviewers: qcolombet, Jim

Reviewed By: Jim

Subscribers: Jim, kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

Too many warnings are being disabled too quickly. Warnings are
important to keeping libc++ correct. This patch re-enables two
warnings: -Wconstant-evaluated and -Wdeprecated-copy.

In future, all warnings disabled for the test suite should require
an attached bug. The bug should state the plan for re-enabling that
warning, or a strong case why it should remain disabled.

Temporarily revert "NFC: DebugInfo: Refactor RangeSpanList to be a struct, like DebugLocStream::List"
as it was causing bot and build failures.

This reverts commit 8e048962.

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

Move these data structures closer together so their emission code can
eventually share more of its implementation.

(except for v4 loclists, which are sufficiently different to not fit
well in this generic implementation)

In subsequent patches I intend to refactor the DebugLoc and ranges data
structures to be more similar so I can common more of the implementation
here.

Since C++11, [depr.impldec]:

The implicit definition of a copy constructor as defaulted is deprecated
if the class has a user-declared copy assignment operator or a
user-declared destructor.

At clang HEAD, -Wdeprecated-copy (included by -Wextra) will warn on such instances.

Reviewed By: EricWF

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

Summary:
Support alloca-referencing dbg.value in hwasan instrumentation.
Update AsmPrinter to emit DW_AT_LLVM_tag_offset when location is in
loclist format.

Reviewers: pcc

Subscribers: srhines, aprantl, hiraditya, llvm-commits

Tags: #llvm

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

Summary:
[libomptarget][nfc] Add declarations of atomic functions for amdgcn

This enables building more source for amdgcn. The functions are usually available
in a hip runtime header, but are duplicated here to decouple the implementation

Reviewers: jdoerfert, ABataev, grokos

Reviewed By: jdoerfert

Subscribers: jvesely, mgorny, jfb, openmp-commits

Tags: #openmp

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

After D71320, target-specific intrinsic headers should be included.