As discussed on the weekly OpenMP meeting on the second of August 2023, the default version
in the OpenMP documentation shoud be changed from OpenMP 5.0 to 5.1.

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

Split from D158952.

This used to be getRuntimePath till https://reviews.llvm.org/D115049
added a fallback search path for Android. As far as I can tell, the
intent has always been to use the first existing path though instead of
actually supporting multiple runtime paths. We can move the existence
checks into getRuntimePath and have it return std::optional, which also
makes the `--print-runtime-dir` behavior much cleaner.

The motivation is a follow-up change to Android runtime path searches,
which is much nicer with this in place.

Reviewed By: phosek, MaskRay

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

The comments date back to NDK r10, which is ancient. libatomic isn't
always needed anymore, and even when it is, it's bundled into
compiler-rt in the NDK so we'll get it automatically. Remove the
unnecessary explicit links.

Reviewed By: srhines

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

Android has only used libc++ for a long time, and since NDK r23, it
also always uses compiler-rt and LLVM's libunwind (which is linked
statically). Reflect these defaults in compiler-rt's build, instead of
requiring the correct settings to always be externally specified.

Reviewed By: srhines

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

If we attempt to use unwind_shared when LIBUNWIND_ENABLE_SHARED is OFF,
we'll get link errors. LIBCXXABI_STATICALLY_LINK_UNWINDER_IN_SHARED_LIBRARY
avoids that, but it seems redundant to have to specify it manually.
Automatically switch libunwind statically when its shared build is
disabled, which also matches compiler-rt [1].

[1] https://github.com/llvm/llvm-project/blob/71bfec762bd970e7834f58c158ddc15f93402d7a/compiler-rt/CMakeLists.txt#L238-L240

Reviewed By: #libc_abi, phosek

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

This reverts commit 8e946fec after
restoring the test-pbp.exe file.

Reviewed By: kiranchandramohan

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

We only had |= and &= which was annoying.

This removes and replaces usage of a few LowLevelAllocators with a single one
provided by sanitizer_common. Functionally, there should be no difference
between using different allocators vs the same one. This works really well
with D158783 which controls the size of each allocator mmap to significantly
reduce fragmentation.

This doesn't remove them all, mainly the ones used by asan and the flag parser.

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

65536 bytes

The LowLevelAllocator is a helper class used by many sanitizer internals
for anonymously mmaping stuff. The allocator (usually) maps one page at
a time, but this can lead to a lot of fragmentation if the allocator is
heavily used. The flag parser is an example of this where it needs to do
lots of string copying that need to exist for a variable length of time.

This adds a macro for specifying the number of pages the LowLevelAllocator
can make at a time, which locally I've found to significantly help reduce
fragmentation and help run the scudo allocator tests in an asan-instrumented
build on riscv Sv39. This is a static macro rather than a value that could
be provided via an env variable because flag parsing is one of the earliest
consumers of the LowLevelAllocator, so this should be set before its ever used.

Note this will mainly help instances of the LowLevelAllocator that are heavily
used, but instances of the LowLevelAllocator that do a small fixed number
of allocations won't benefit as much from this. This can be alleviated though
if we instead consolidate all of them to one single LowLevelAllocator (D158786).

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

Patch D147740 Change back to std::unordered_map for SampleProfileMap because it has reference validity, the change to use llvm::DenseMap is moved to a different patch.

Reviewed By: wenlei, ayermolo

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

Currently, for MS, the linkage for the inheriting constructors is set to
internal.  However, the comdat attribute is also set like:

define internal noundef ptr @"??0?$B@_N@@qeaa@AEBVF@@aebua@@@z"(ptr noundef nonnull returned align 1 dereferenceable(1) %this, ptr noundef nonnull align 1 dereferenceable(1) %0, ptr noundef nonnull align 1 dereferenceable(1) %1) unnamed_addr comdat

This could cause linker to fail.

The change is to remove comdat attribute for the inheriting constructor
to make linker happy.

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

Accessing the PLT entries of hooks can lead a certain amount of
performance overhead. This is observed on certain tasks which will do a
bunch of malloc/free and their throughputs are impacted by the null
check of hooks.

Also add SCUDO_ENABLE_HOOKS_TESTS to select if we want to run the hook
tests. On some platforms they may have different ways to run the
wrappers tests (end-to-end tests) and test the hooks along with the
wrappers tests may not be feasible. Provide an option to turn it ON/OFF.

By default, we only verify the hook behavior in the scudo standalone
tests if SCUDO_ENABLE_HOOKS is defined or COMPILER_RT_DEBUG is true.

Reviewed By: cferris, fabio-d

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

They were reported in https://lab.llvm.org/buildbot/#/builders/68/builds/58956 and the fix is simple.

Jump tables on AArch64 are label-relative rather than table-relative, so
having jump table destinations that are in different sections causes
problems with relocation. Jump table lookups have a max range of 1MB, so
all destinations must be in the same section as the lookup code. Both of
these restrictions can be mitigated with some careful and complex logic,
but doing so doesn't gain a huge performance benefit.

Efficiently ensuring jump tables are correct and can be compressed on
AArch64 is a TODO item. In the meantime, don't split blocks that can
cause problems.

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

The REPL has a default tab size of 4 spaces, which seems to be a bit too much. The reason is that the REPL transforms tabs into spaces, and therefore whenever you want to manually deindent, you need to delete at least 4 characters. On the other hand, using 2 as default results in less keystrokes, without hurting readability.

For nonexistent or inaccessible files, we're returning NO, which is
indeed true, but we should return UNKNOWN instead.

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

For now check-fuzzer is just a cmake target that depends
on different check-fuzzer-xxx lit test targets. This causes
check-fuzzer get seperate lit test results like this:

```
********************
********************
Failed Tests (1):
  libFuzzer :: fuzzer-flags.test

Testing Time: 19.80s
  Unsupported      :   7
  Passed           : 128
  Expectedly Failed:   3
  Failed           :   1
make[3]: *** [projects/compiler-rt/test/fuzzer/CMakeFiles/check-fuzzer-default-x86_64.dir/build.make:71: projects/compiler-rt/test/fuzzer/CMakeFiles/check-fuzzer-default-x86_64] Error 1
make[2]: *** [CMakeFiles/Makefile2:36745: projects/compiler-rt/test/fuzzer/CMakeFiles/check-fuzzer-default-x86_64.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
--

********************
********************
Failed Tests (1):
  libFuzzer :: fuzzer-flags.test

Testing Time: 24.33s
  Unsupported:  21
  Passed     : 117
  Failed     :   1
make[3]: *** [projects/compiler-...

In internal google builds, MainExecPath doesn't go to the directory with `clang`.
Fall back to using Argv0 if MainExecPath doesn't find any clangs.

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

Add config name for fuzzer lit test, to make it easier to identify failures are with which config.

Before this change, same lit tests with different configs will share the same test name.
```
********************
Failed Tests (2):
  libFuzzer :: fuzzer-flags.test
  libFuzzer :: fuzzer-flags.test
```
Actually this is a failure of two lit tests(two configs of the same test).

With this change, the names will be different.
```
********************
Failed Tests (2):
  libFuzzer-i386-default-Linux ::fuzzer-flags.test
  libFuzzer-x86_64-default-Linux :: fuzzer-flags.test
```

Reviewed By: MaskRay, vitalybuka

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

This commit enables DRR rewriter to match a fixed number of sub-operands
as a variadic operand.

Differential Review: https://reviews.llvm.org/D157359

This reverts commit 653f7769.

This breaks lldb-aarch64-windows buildbot.
I have reproduced the issue on x86_64 Windows as well.
https://lab.llvm.org/buildbot/#/builders/219/builds/5130

80332312 made this test pass
in MinGW environments, even if it still is failing in MSVC
environments.

Some options are only claimed in AddX86TargetArgs/etc (called by
Clang::RenderTargetOptions).
For assembler input, `Add*TargetArgs` is not called. If an option is
unclaimed, it either leads to a -Wunused-command-line-argument warning
or an error (if `TargetSpecific` is set)
```
// clang '-###' --target=x86_64 -mfpmath=sse -c a.s
clang: error: unsupported option '-mfpmath=sse' for target 'x86_64'
```

For -mfpmath=, it's actually claimed by RenderFloatingPointOptions,
which should be moved to AddARMTargetArgs/AddX86TargetArgs later
(non-AArch32-non-x86 targets give a frontend error).
This change is localized and similar to D153691, for release/17.x
backporting.

Fix https://github.com/llvm/llvm-project/issues/65023

Reviewed By: thesamesam

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

When using debug info correlation, value profiling needs to be switched off.
So, we are only merging counter sections. In that case the existance of data
section is just used to provide an extra check in case of corrupted profile.

This patch performs counter merging by iterating the counter section by counter
size and add them together.

Reviewed By: ellis, MaskRay

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

After 6fb08d8f,`clang/test/Modules/ModuleDebugInfoDwoId.cpp` started failing on a number of big-endian build bots (clang-ppc64be-linux-multistage, clang-ppc64be-linux-test-suite). This patch attempts to fix that by creating an API on `llvm::BitstreamWriter` that allows backpatching individual bytes. This API is then used from `clang::ASTWriter` to avoid endianness mismatch.

Original commit message:
"
This patch enabled code completion for ClangREPL. The feature was built upon
three existing Clang components: a list completer for LineEditor, a
CompletionConsumer from SemaCodeCompletion, and the ASTUnit::codeComplete method.
The first component serves as the main entry point of handling interactive inputs.

Because a completion point for a compiler instance has to be unchanged once it
is set, an incremental compiler instance is created for each code
completion. Such a compiler instance carries over AST context source from the
main interpreter compiler in order to obtain declarations or bindings from
previous input in the same REPL session.

The most important API codeComplete in Interpreter/CodeCompletion is a thin
wrapper that calls with ASTUnit::codeComplete with necessary arguments, such as
a code completion point and a ReplCompletionConsumer, which communicates
completion results from SemaCodeCompletion back to the list completer for the
REPL.

In addition, PCC_TopLevelOrExpression and CCC_TopLevelOrExpression` top levels
were added so that SemaCodeCompletion can treat top level statements like
expression statements at the REPL. For example,

clang-repl> int foo = 42;
clang-repl> f<tab>

From a parser's persective, the cursor is at a top level. If we used code
completion without any changes, PCC_Namespace would be supplied to
Sema::CodeCompleteOrdinaryName, and thus the completion results would not
include foo.

Currently, the way we use PCC_TopLevelOrExpression and
CCC_TopLevelOrExpression is no different from the way we use PCC_Statement
and CCC_Statement respectively.

Differential revision: https://reviews.llvm.org/D154382
"

The new patch also fixes clangd and several memory issues that the bots reported
and upload the missing files.

This reverts commit 5ab25a42 due to forgotten
files.

Breaks windows https://lab.llvm.org/buildbot/#/builders/127/builds/54239

This reverts commit d8099203.

Original commit message:
"
This patch enabled code completion for ClangREPL. The feature was built upon
three existing Clang components: a list completer for LineEditor, a
CompletionConsumer from SemaCodeCompletion, and the ASTUnit::codeComplete method.
The first component serves as the main entry point of handling interactive inputs.

Because a completion point for a compiler instance has to be unchanged once it
is set, an incremental compiler instance is created for each code
completion. Such a compiler instance carries over AST context source from the
main interpreter compiler in order to obtain declarations or bindings from
previous input in the same REPL session.

The most important API codeComplete in Interpreter/CodeCompletion is a thin
wrapper that calls with ASTUnit::codeComplete with necessary arguments, such as
a code completion point and a ReplCompletionConsumer, which communicates
completion results from SemaCodeCompletion back to the list completer for the
REPL.

In addition, PCC_TopLevelOrExpression and CCC_TopLevelOrExpression` top levels
were added so that SemaCodeCompletion can treat top level statements like
expression statements at the REPL. For example,

clang-repl> int foo = 42;
clang-repl> f<tab>

From a parser's persective, the cursor is at a top level. If we used code
completion without any changes, PCC_Namespace would be supplied to
Sema::CodeCompleteOrdinaryName, and thus the completion results would not
include foo.

Currently, the way we use PCC_TopLevelOrExpression and
CCC_TopLevelOrExpression is no different from the way we use PCC_Statement
and CCC_Statement respectively.

Differential revision: https://reviews.llvm.org/D154382
"

The new patch also fixes clangd and several memory issues that the bots reported.

Add Leading_upper_snake_case to IdentifierNamingCheck naming convention.

Fixes: #42451

Reviewed By: PiotrZSL

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

Update release notes for modernize-use-std-print check.
Post D156616 action.

The modernize-use-std-print check would get confused if it had to
re-order field-width and precision arguments at the same time as adding
casts or removing calls to c_str().

Fix this by tracking the argument indices and combining c_str() removal
with argument re-ordering. Add missing test cases to lit check.

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

Reviewed By: PiotrZSL

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

After https://reviews.llvm.org/D153092, for targets that use a non-default AS for globals, an "interesting" situation arises around typeid and its paired type, type_info:

- on the AST level, the type_info interface is defined with default / generic addresses, be it for function arguments, or for this;
- in IR, type_info values are globals, and thus pointers to type_info values are pointers to global

This leads to a mismatch between the function signature / formal type of the argument, and its actual type. Currently we try to handle such mismatches via `bitcast`, but that is wrong in this case, since an `ascast` is required. This patch ensures that iff the pointer to `type_info` points to a non-default AS, an ascast is inserted so as to match the `typeid` interface / return value type.

Reviewed by: yaxunl

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

Fails with "The procedure entry point SetThreadDescription could not be located in the dynamic link library..."

This reverts commit cf76ddcb.