This patch adds DT_STRSZ into the dynamic section, which was absent
previously. This was a bug and caused failures in other tools.

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

Previously D113336 makes RISCVTargetInfo::initFeatureMap return the results
processed by RISCVISAInfo, which only consists of ISA features and misses
non-ISA features like `relax` and `save-restore`.

This patch fixes the problem.

Reviewed By: junparser

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

Third attempt to fix a bot failure from
634da7a1 on an Android bot:
https://lab.llvm.org/buildbot#builders/77/builds/14339

My last attempt used an approach from another test where chmod was not
working of using a bad character in the path name. But it looks like
this trick only works on Windows.

Instead, restore the original version of this test before my change at
634da7a1 and move the bad path test to
a new test file, marking it unsupported on Android.

The slab delta (used to link as if allocated at a specified address) should
remain constant.The update to the delta was accidentally introduced in
962a2479, but hasn't caused any failures as it only breaks in an obvious
way for multi-file exec uses (our regression tests are all -noexec, and tend to
be single-file).

No testcase here: this is an obscure utility for testing support, and an
uncommon use-case. If the slab allocator is ever moved into LLVM we could add
a unit test to catch this.

This enables fshl to be matched earlier on X86

  %6 = lshr i32 %3, 1
  %7 = select i1 %4, i32 -2147483648, i32 0
  %8 = or i32 %6, %7

X86 uses i8 for shift amounts. SelectionDAGBuilder creates the
ISD::SRL with an i8 shift type. DAGCombiner turns the select into
an ISD::SHL. Prior to this patch it would use i32 for the shift
amount. fshl matching failed because the shift amounts have different
types. LegalizeDAG fixes the ISD::SHL shift amount to i8. This
allowed fshl matching to succeed.

With this patch, the ISD::SHL will be created with an i8 shift
amount. This allows the fshl to match immediately.

No test case beause we still end up with a fshl either way.

Handles the case where Previous doesn't come before LastPrev incorrectly.
Fix https://github.com/llvm/llvm-project/issues/53483

Reviewed By: fhahn

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

Second attempt to fix a bot failure from
634da7a1 on an Android bot:
https://lab.llvm.org/buildbot#builders/77/builds/14339

With the fix in 986afe84 there was a
different issue, because we need the fully qualified path name to the
binary, which is only available in arg[0]. New failure:
https://lab.llvm.org/buildbot/#/builders/77/builds/14346/steps/16/logs/stdio

Restructure the test so both attempts are made from the same invocation,
which sets up the bad paths directly.

[clang-format] Handle PointerAlignment in `if` and `switch` statements with initializers (C++17) the same way as in `for` loops.

Reviewed By: MyDeveloperDay, owenpan

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

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

Braces in loops and in `if` statements with leading (block) comments were formatted according to `BraceWrapping.AfterFunction` and not `AllowShortBlocksOnASingleLine`/`AllowShortLoopsOnASingleLine`/`AllowShortIfStatementsOnASingleLine`.

Previously, the code:
```
while (true) {
  f();
}
/*comment*/ while (true) {
  f();
}
```

was incorrectly formatted to:
```
while (true) {
  f();
}
/*comment*/ while (true) { f(); }
```

when using config:
```
BasedOnStyle: LLVM
BreakBeforeBraces: Custom
BraceWrapping:
  AfterFunction: false
AllowShortBlocksOnASingleLine: false
AllowShortLoopsOnASingleLine: false
```

and it was (correctly but by chance) formatted to:
```
while (true) {
  f();
}
/*comment*/ while (true) {
  f();
}
```

when using enabling brace wrapping after functions:
```
BasedOnStyle: LLVM
BreakBeforeBraces: Custom
BraceWrapping:
  AfterFunction: true
AllowShortBlocksOnASingleLine: false
AllowShortLoopsOnASingleLine: false
```

Reviewed By: MyDeveloperDay, HazardyKnusperkeks, owenpan

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

Attempts to fix a bot failure from
634da7a1 on an Android bot:
https://lab.llvm.org/buildbot#builders/77/builds/14339

It appears that the chmod is not making the directory unwritable as
expected on this system for some reason. Adopt an approach used in
compiler-rt/test/fuzzer/fuzzer-dirs.test for systems with
non-functioning chmod by including illegal characters in directory.

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

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

Need to add an assert about this->takeName(this). This restriction is already documented, so this is just an NFC check.
Without this assertion (as prescribed by original comments for this API), name deletion or down-stream assert failures may occur in other routines: e.g. at the beginning of replaceAllUsesWith() below.

Reviewed By: aeubanks

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

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

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

Fixes a MemCpyOpt miscompile with opaque pointers.
This function can be further cleaned up, but let's just fix the miscompile first.

Reviewed By: #opaque-pointers, nikic

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

This wasn't running because of the missing colon

This reverts commit af45d0fd.

This causes assertions failures when compiling the Linux kernel. See
https://reviews.llvm.org/D118663 for a reduced reproducer.

This adds support for encoding and decoding the LC_FUNCTION_STARTS load
command payload.

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

Add a DirExists mechanism, modeled after FileExists. Use it to guard
creation of the report path directory.

This should avoid failures running the sanitizer in a sandbox where the
file creation attempt causes hard failures, even for an existing
directory. Problem reported on D109794 for ChromeOS in sandbox
(https://issuetracker.google.com/209296420).

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

This is a retry of b4b97ec8 - that was reverted because it
could cause miscompiles by illegally reordering memory operations.
A new test based on #53695 is added here to verify we do not have
that same problem.

extract_vec_elt (load X), C --> scalar load (X+C)

As noted in the comment, DAGCombiner has this fold -- and the code in this
patch is adapted from DAGCombiner::scalarizeExtractedVectorLoad() -- but
x86 should benefit even if the loaded vector has other uses as long as we
apply some other x86-specific conditions. The motivating example from #50310
is shown in vec_int_to_fp.ll.

Fixes #50310
Fixes #53695

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

This often occurs when the accumulator is larger than the source vector element, such as some of the tests mentioned in Issue #42019

The pointers are referenced immediately, so assert the cast is correct instead of returning nullptr

without prototypes. This patch converts the function signatures to have
a prototype for the situations where the test is not specific to K&R C
declarations. e.g.,

  void func();

becomes

  void func(void);

This is the ninth batch of tests being updated (there are a
significant number of other tests left to be updated).

The noalias metadata checks re not really relevant for the test and
slight changes to metadata numbering can have large knock-on effects
causing large noise in test diff.

Device clause when it occurs with **target enter data** and **target exit data** must be declared with some non negative value. So some changes were made to evaluate the device clause argument to non negative value and throw the expected error when it takes negative value as argument.

Reviewed By: clementval

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

Add real uses to some tests, to ensure dead instructions cannot be directly
removed.

When, for example, using "ascend" operator, I was wondering whether
the bit order of the dag argument will be reversed in ascend order
as well.

This patch clarifies it.

Reviewed By: myhsu

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