This patch is a continuation of 6f8b33f6 and eliminates the
{Get,Set}PropertyAtIndexAsFileSpec functions.

There's no reason for FileSpecList to live in lldb/Core while FileSpec
lives in lldb/Utility. Move FileSpecList next to FileSpec.

Reviewed By: craig.topper

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

After 6f8b33f6 this function has no callers anymore.

This revision makes ShuffleBlockStrategy deterministic by replacing
SmallPtrSet with other data structures that has a deterministic iteration
order.

Reviewed By: Peter

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

Make sure that the upper bits of the offset is placed in bits 20-21 of the
instruction word.

This fixes the encoding of backwards (negative offset) BPr branches.

(Previously, the upper two bits of the offset would overwrite parts of the rs1
field, causing it to branch on the wrong register, with the wrong offset)

Reviewed By: arsenm

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

Otherwise I think we extract and use a build_vector. There may be
some more improvements that can be made and there might be some
cases that we should do something different for, but this seemed like a
decent starting point.

Reviewed By: luke

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

Previously this wasn't implemented because it's effectively a no-op.
However, this should be safe to emit on sm_60 architectures. It's
important because it carries semantic importance for whether or not
something can be moved. So we should always emit this instrinsic.

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

Fix bug constants and sub instructions

When finding constants in a chain starting with the RHS operator of
sub instructions, we were negating the constant before zero extending
it, which is incorrect.

Unfortunately, I was unable to find a simple way to implement this
transformation correctly, so for now I just disabled this optimization
for constants that feed into the RHS of a sub.

Resolves #62379

Transformation from alive2.llvm.org:

    define i16 @src(i8 %a, i8 %b, i8 %c) {
    entry:
    %0 = sub nuw nsw i8 %c, %a
    %1 = sub nuw nsw i8 %b, %0
    %2 = zext i8 %1 to i16
    ret i16 %2
    }

    Before/Bad:

    define i16 @tgt(i8 %a, i8 %b, i8 %c) {
    entry:
    %0 = zext i8 %a to i16
    %1 = zext i8 %b to i16
    %c_neg = sub i8 0, %c
    %c_zext = zext i8 %c_neg to i16
    %2 = sub i16 0, %0
    %3 = sub i16 %1, %2
    %4 = add i16 %3, %c_zext
    ret i16 %4
    }

    Correct:

    define i16 @tgt(i8 %a, i8 %b, i8 %c) {
    entry:
    %0 = zext i8 %a to i16
    %1 = zext i8 %b to i16
    %c_zext = zext i8 %c to i16
    %c_neg = sub i16 0, %c_zext
    %2 = sub i16 0, %0
    %3 = sub i16 %1, %2
    %4 = add i16 %3, %c_neg
    ret i16 %4
    }

Reviewed By: nikic

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

Reviewed By: jrtc27

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

This revision is a part of a series of patches extending
AddressSanitizer C++ container overflow detection
capabilities by adding annotations, similar to those existing
in std::vector, to std::string and std::deque collections.
These changes allow ASan to detect cases when the instrumented
program accesses memory which is internally allocated by
the collection but is still not in-use (accesses before or
after the stored elements for std::deque, or between the size and
capacity bounds for std::string).

The motivation for the research and those changes was a bug,
found by Trail of Bits, in a real code where an out-of-bounds read
could happen as two strings were compared via a std::equals function
that took iter1_begin, iter1_end, iter2_begin iterators
(with a custom comparison function).
When object iter1 was longer than iter2, read out-of-bounds on iter2
could happen. Container sanitization would detect it.

In revision D132522, support for non-aligned memory buffers (sharing
first/last granule with other objects) was added, therefore the
check for standard allocator is not necessary anymore.
This patch removes the check in std::vector annotation member
function (__annotate_contiguous_container) to support
different allocators.

Additionally, this revision fixes unpoisoning in std::vector.
It guarantees that __alloc_traits::deallocate may access returned memory.
Originally suggested in D144155 revision.

If you have any questions, please email:
 - advenam.tacet@trailofbits.com
 - disconnect3d@trailofbits.com

Reviewed By: #libc, #sanitizers, philnik, vitalybuka, ldionne

Spies: mikhail.ramalho, manojgupta, ldionne, AntonBikineev, ayzhao, hans, EricWF, philnik, #sanitizers, libcxx-commits

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

The GPU has a different execution model to standard `_start`
implementations. On the GPU, all threads are active at the start of a
kernel. In order to correctly intitialize and call the constructors we
want single threaded semantics. Previously, this was done using a
makeshift global barrier with atomics. However, it should be easier to
simply put the portions of the code that must be single threaded in
separate kernels and then call those with only one thread. Generally,
mixing global state between kernel launches makes optimizations more
difficult, similarly to calling a function outside of the TU, but for
testing it is better to be correct.

Depends on D149527 D148943

Reviewed By: JonChesterfield

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

The execution model of the GPU expects that groups of threads will
execute in lock-step in SIMD fashion. It's both important for
performance and correctness that we treat this as the smallest possible
granularity for an RPC operation. Thus, we map multiple threads to a
single larger buffer and ship that across the wire.

This patch makes the necessary changes to support executing the RPC on
the GPU with multiple threads. This requires some workarounds to mimic
the model when handling the protocol from the CPU. I'm not completely
happy with some of the workarounds required, but I think it should work.

Uses some of the implementation details from D148191.

Reviewed By: JonChesterfield

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

Reviewed By: fakepaper56

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

This reverts commit 3a540229.
A new regression is discovered and needs to be investigated.

This reverts commit 04aa943b.

This broke the debian buildbot and I'm not sure why. Reverting so I can
investigate.

Use templates to simplify {Get,Set}PropertyAtIndex. It has always
bothered me how cumbersome those calls are when adding new properties.
After this patch, SetPropertyAtIndex infers the type from its arguments
and GetPropertyAtIndex required a single template argument for the
return value. As an added benefit, this enables us to remove a bunch of
wrappers from UserSettingsController and OptionValueProperties.

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

There are many situations where we'll iterate over a SymbolContextList
with the pattern:
```
SymbolContextList sc_list;
// Fill in sc_list here
for (auto i = 0; i < sc_list.GetSize(); i++) {
  SymbolContext sc;
  sc_list.GetSymbolAtContext(i, sc);

  // Do work with sc
}
```
Adding an iterator to iterate over the instances directly means we don't
have to do bounds checking or create a copy of every element of the
SymbolContextList.

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

This patch updates the struct dirent to be on par with glibc (by adding
a missing d_type member) and update the readdir call to use SYS_getdents64
instead of SYS_getdents.

Reviewed By: sivachandra

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

Update format to stick to https://llvm.org/docs/CodingStandards.html#don-t-use-braces-on-simple-single-statement-bodies-of-if-else-loop-statements

Carefully work around not knowing the thread mask that nvptx intrinsic
functions require.

If the warp is converged when calling try_lock, a single rpc call will handle
all lanes within it. Otherwise more than one rpc call with thread masks that
compose to the unknown one will occur.

Reviewed By: jhuber6

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

This reverts commit b1323738.

Carefully work around not knowing the thread mask that nvptx intrinsic
functions require.

If the warp is converged when calling try_lock, a single rpc call will handle
all lanes within it. Otherwise more than one rpc call with thread masks that
compose to the unknown one will occur.

Reviewed By: jhuber6

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

This is more useful for debug/test than getNullabilitySpelling:
 - default form has uglifying underscores
 - non-default form crashes on NullableResult
 - both return unhelpfully verbose strings for Unspecified
 - operator<< works with gtest, formatv, etc

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

This revision is part of our efforts to support container annotations with (almost) every allocator.
That patch is necessary to enable support for most annotations (D136765). Without a way to turn off annotations, it's hard to use ASan with area allocators (no calls to destructors).

This is an answer to a request about it. This patch provides a solution to the aforementioned issue by introducing a new template structure `__asan_annotate_container_with_allocator`, which allows the disabling of container annotations for a specific allocator.

This patch also introduces `_LIBCPP_HAS_ASAN_CONTAINER_ANNOTATIONS_FOR_ALL_ALLOCATORS` FTM.

To turn off annotations, it is sufficient to create a template specialization with a false value using a [Unary Type Trait](https://en.cppreference.com/w/cpp/types/integral_constant).

The proposed structure is being used in the code enabling annotations for all allocators in `std::vector`, `std::basic_string`, and `std::deque`. (D136765 D146214 D146815)

Possibility to do it was added to ASan API in rGdd1b7b79 commit.

For context on not calling a destructor, look at https://eel.is/c++draft/basic.life#5 and notes there, you may also read a discussion in D136765.

Reviewed By: ldionne, philnik, #libc, hans

Spies: EricWF, mikhail.ramalho, #sanitizers, libcxx-commits, hans, vitalybuka

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

For the wider context of this change, see the RFC at
https://discourse.llvm.org/t/70086.

After this change, global and local variables of reference type are associated
directly with the `StorageLocation` of the referenced object instead of the
`StorageLocation` of a `ReferenceValue`.

Some tests that explicitly check for an existence of `ReferenceValue` for a
variable of reference type have been modified accordingly.

As discussed in the RFC, I have added an assertion to `Environment::join()` to
check that if both environments contain an entry for the same declaration in
`DeclToLoc`, they both map to the same `StorageLocation`. As discussed in
https://discourse.llvm.org/t/70086/5, this also necessitates removing
declarations from `DeclToLoc` when they go out of scope.

In the RFC, I proposed a gradual migration for this change, but it appears
that all of the callers of `Environment::setStorageLocation(const ValueDecl &,
SkipPast` are in the dataflow framework itself, and that there are only a few of
them.

As this is the function whose semantics are changing in a way that callers
potentially need to adapt to, I've decided to change the semantics of the
function directly.

The semantics of `getStorageLocation(const ValueDecl &, SkipPast SP` now no
longer depend on the behavior of the `SP` parameter. (There don't appear to be
any callers that use `SkipPast::ReferenceThenPointer`, so I've added an
assertion that forbids this usage.)

This patch adds a default argument for the `SP` parameter and removes the
explicit `SP` argument at the callsites that are touched by this change. A
followup patch will remove the argument from the remaining callsites,
allowing the `SkipPast` parameter to be removed entirely. (I don't want to do
that in this patch so that semantics-changing changes can be reviewed separately
from semantics-neutral changes.)

Reviewed By: ymandel, xazax.hun, gribozavr2

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

The pass should not try to revectorize instructions with constant
operands, which were not folded by the IRBuilder. It prevents the
non-terminating loop in the SLP vectorizer for non foldable constant
operations.

This is what the code assumed but never actually checked.

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

Reviewed By: nikic

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

I have a patch to refactor this class and I'd like a unittest in place
to make sure I don't break anything.

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

This reverts commit 09ceb472.

Reorder cases to make sure they are ordered properly in preparation
for D149081.

Add suport for MASK style watchpoints on AArch64 in debugserver
on Darwin systems, for watching power-of-2 sized memory ranges.
More work needed in lldb before this can be exposed to the user
(because they will often try watching memory ranges that are not
exactly power-of-2 in size/alignment) but this is the first part
of adding that capability.

Differential Revision: https://reviews.llvm.org/D149792
rdar://108233371

If a remote stub provides the addressing_bits kv pair in
the stop reply packet, update the Process address masks with
that value as it possibly changes during the process runtime.
This is an unusual situation, most likely a JTAG remote stub
and some very early startup code that is setting up the page
tables.  Nearly all debug sessions will have a single address
mask that cannot change during the lifetime of a Process.

Differential Revision: https://reviews.llvm.org/D149803
rdar://61900565