Commit 395124 "NVPTX: Don't insert an extra empty line at the end of the last section"
changed the length of the kernel payload. Update the regression test to the new binary size.

If lldb was run in capture mode, but no reproducer was generated, make
sure we clean up the reproducer directory.

Summary:
This patch adds a custom ISA for vector functions for internal use
in LLVM. The <isa> token is set to "_LLVM_", and it is not attached
to any specific instruction Vector ISA, or Vector Function ABI.

The ISA is used as a token for handling Vector Function ABI-style
vectorization for those vector functions that are not directly
associated to any existing Vector Function ABI (for example, some of
the vector functions exposed by TargetLibraryInfo). The demangling
function for this ISA in a Vector Function ABI context is set to be
the same as the common one shared between X86 and AArch64.

Reviewers: jdoerfert, sdesmalen, simoll

Subscribers: kristof.beyls, hiraditya, llvm-commits

Tags: #llvm

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

8548 CPU is GCC's name for the e500v2, so accept this in clang.  The
e500v2 doesn't support lwsync, so define __NO_LWSYNC__ for this as well,
as GCC does.

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

This is the same as the add case, but inverts the operation type.

This avoids regressions in a future patch.

Previously this would default to 256, not the maximum supported size
of 1024. Using a maximum lower than the hardware maximum requires
language runtimes to enforce this limit for correctness, which no
language has correctly done. Switch the default to the conservatively
correct maximum, and force frontends to opt-in to the more optimal 256
default maximum.

I don't really understand why the changes in occupancy-levels.ll
increased the computed occupancy, which I expected to decrease. I'm
not sure if these tests should be forcing the old maximum.

While some targets allow encoding 2048, this was never tested or
supported.

This patch adds core definitions in lldb ArchSpecs for armv8l and armv7l cores.

This was needed because on Linux running on 32-bit Arm v8 we are returned
armv8l in case we are running 32-bit sysroot on 64bit kernel. In case of 32-bit
kernel and 32-bit sysroot running on arm v8 hardware we are returned armv7l.
This is quite common when we run 32 bit arm using docker container.

Signed-off-by: Muhammad Omair Javaid <omair.javaid@linaro.org>

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

'clang'.

This is not true in practice in some content-addressed file systems.

This is a fix for PR43315. An assertion error is hit for this minimal example:

```
//clang -cc1 -triple x86_64-- -S tstVMStructRC-min.cpp
int (a b)();  // Assertion `Chunk.Kind == DeclaratorChunk::Function' failed.
```

This is because we do not cover the case in the FunctionTypeUnwrapper where it
receives a MacroQualifiedType. We have not run into this earlier because this
is a unique case where the __attribute__ contains both __cdecl__ and
__regparm__ (in that order), and we are compiling for x86_64. Changing the
architecture or the order of __cdecl__ and __regparm__ does not raise the
assertion.

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

Reverting to figure out if it's a problem in python or the compiler for now.

This reverts commit 885a05f4.

A few years back a similar change was made for getenv since neither function is supported on the PS4 platform.

Recently, commit d889d1ef added a call to setenv in compiler-rt which was causing linking errors because the symbol was not found. This fixes that issue by putting in a shim similar to how we previously dealt with the lack of getenv.

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

This avoids some nasty issues with argument passing and lowering of
arbitrary v64i8 shuffles.

[X86] Only pass v64i8/v32i16 as v16i32 on non-avx512bw targets if the v16i32 type won't be split by prefer-vector-width=256

Otherwise just let the v64i8/v32i16 types be split to v32i8/v16i16.

In reality this shouldn't happen because it means we have a 512-bit
vector argument, but min-legal-vector-width says a value less than
512. But a 512-bit argument should have been factored into the
preferred vector width.

Summary:
This patch fixes two problems with the crtbegin.c as written:

1. In do_init, register_frame_info is not guarded by a #define, but in
do_fini, deregister_frame_info is guarded by #ifndef
CRT_HAS_INITFINI_ARRAY. Thus when CRT_HAS_INITFINI_ARRAY is not
defined, frames are registered but then never deregistered.

The frame registry mechanism builds a linked-list from the .so's
static variable do_init.object, and when the .so is unloaded, this
memory becomes invalid and should be deregistered.

Further, libgcc's crtbegin treats the frame registry as independent
from the initfini array mechanism.

This patch fixes this by adding a new #define,
"EH_USE_FRAME_INFO_REGISTRY", which is set by the cmake option
COMPILER_RT_CRT_USE_EH_FRAME_REGISTRY Currently, do_init calls
register_frame_info, and then calls the binary's constructors. This
allows constructors to safely use libunwind. However, do_fini calls
deregister_frame_info and then calls the binary's destructors. This
prevents destructors from safely using libunwind.

This patch also switches that ordering, so that destructors can safely
use libunwind. As it happens, this is a fairly common scenario for
thread sanitizer.

Some warnings in -Wtautological-compare subgroups are DefaultIgnore.
Adding this group to -Wmost, which is part of -Wall, will aid in their
discoverability.

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

Enable to generate BTF_KIND_VARs for non-static
default-section globals which is not allowed previously.
Modified the existing test case to accommodate the new change.

Also removed unused linkage enum members VAR_GLOBAL_TENTATIVE and
VAR_GLOBAL_EXTERNAL.

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

Summary:
If there are any internal methods whose address was taken, conclude there is nothing known in relation of any other internal method and a global.

Reviewers: nlopes, sanjoy.google

Subscribers: hiraditya, llvm-commits

Tags: #llvm

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

This fixes the following warning for developers:

  Target 'liblldb' was changed to a FRAMEWORK sometime after install().  This
  may result in the wrong install DESTINATION.  Set the FRAMEWORK property
  earlier.

The solution is to pass the FRAMEWORK flag to add_lldb_library and set
the target property before install(). For now liblldb is the only
customer.

Resolves PR38906, PR40898.

Summary:
By additional regex match, grouping of main include can be enabled in files that are not normally considered as a C/C++ source code.
For example, this might be useful in templated code, where template implementations are being held in *Impl.hpp files.
On the occassion, 'assume-filename' option description was reworded as it was misleading. It has nothing to do with `style=file` option and it does not influence sourced style filename.

Reviewers: rsmith, ioeric, krasimir, sylvestre.ledru, MyDeveloperDay

Reviewed By: MyDeveloperDay

Subscribers: MyDeveloperDay, cfe-commits

Patch by:  furdyna

Tags: #clang

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

Centralize the logic to remove debugserver from
LLVM_DISTRIBUTION_COMPONENTS when LLDB_USE_SYSTEM_DEBUGSERVER is
enabled. Now this happens regardless of whether the tests are enabled.

Fix the modeling for loads and stores using the register offset addresing mode.

Fix predicates related to the register offset addressing mode.

Root cause is VectorBlockGenerator::copyStmt iterates all instructions
in basic block, however some load instructions may be not unnecessary
thus removed by simplification. As a result, these load instructions
don't have a corresponding array.

Looking at BlockGenerator::copyBB, it only iterates instructions list
of ScopStmt. Given it must be a block type scop in case of
vectorization, I think we should do the same in
VectorBlockGenerator::copyStmt.

Patch by bin.narwal <bin.narwal@gmail.com>

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

Let the checkers use a reference instead of a copy in a range-based
for loop.

This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.

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

The std::pair<const clang::ValueDecl *, llvm::ArrayRef<clang::OMPClauseMappableExprCommon::MappableComponent>>
type will be copied in a range-based for loop. Make the copy explicit to
avoid the -Wrange-loop-analysis warning.

This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.

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

The AssociationIteratorTy type will be copied in a range-based for loop.
Make the copy explicit to avoid the -Wrange-loop-analysis warning.

This avoids new warnings due to D68912 adds -Wrange-loop-analysis to -Wall.

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

[LLDB][Formatters] Re-enable std::function formatter with fixes to improve non-cached lookup performance

Performance issues lead to the libc++ std::function formatter to be disabled. We addressed some of those performance issues by adding caching see D67111
This PR fixes the first lookup performance by not using FindSymbolsMatchingRegExAndType(...) and instead finding the compilation unit the std::function wrapped callable should be in and then searching for the callable directly in the CU.

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

The parsing error tests in ELF/redefine-symbols.test are not specific to ELF.
Move them to redefine-symbols.test.
Add COFF/redefine-symbols.test for COFF specific tests.

Also fix the documentation regarding --redefine-syms: the old and new
names are separated by whitespace, not an equals sign.

Reviewed By: mstorsjo

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

Catch up with an API change.

These relocations are specified by the ARM EHABI (section 6.3). As I understand
it, their purpose is to accommodate unwinder implementations that wish to
reduce code size by placing the implementations of the compact unwinding
decoders in a separate translation unit, and using extern weak symbols to
refer to them from the main unwinder implementation, so that they are only
linked when something in the binary needs them in order to unwind.

However, neither of the unwinders used on Android (libgcc, LLVM libunwind)
use this technique, and in fact emitting these relocations ends up being
counterproductive to code size because they cause a copy of the unwinder
to be statically linked into most binaries, regardless of whether it is
actually needed. Furthermore, these relocations create circular dependencies
(between libc and the unwinder) in cases where the unwinder is dynamically
linked and libc contains compact unwind info.

Therefore, deviate from the EHABI here and stop emitting these relocations
on Android.

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

- Dependent components need linking directly.

reduction initializers.

Better to use copy constructor at the initialization of the declare
reduction construct rather than assignment operator.

We build with `-nostdinc++` and add our own header path via
`LIBCXXABI_LIBCXX_INCLUDES`.  However cmake tried to be clever and if
`LIBCXXABI_LIBCXX_INCLUDES` happens to match the compilers system path
it will remove the `-I` flag meaning we can't access any C++ headers.

Ideally cmake would be able see that we are using `-nostdinc++` and
disable this behaviour.

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