Apparently modern versions of ounit2 can only be found as "ounit2"
rather than "oUnit" version 2.  Update the CMake check to support both
variants.  This makes the OCaml tests run again with ounit2-2.2.4.

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

A significant number of our tests in C accidentally use functions
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 eighth batch of tests being updated (there are a
significant number of other tests left to be updated).

Just use dyn_cast<> to determine literal + container values from the binop

[clang-doc] populateParentNamespaces - use cast<> instead of dyn_cast<> to avoid dereference of nullptr

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

It's only later iterations of the loop where the getParent() call might return nullptr

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

[clang][sema] Sema::CheckFreeArguments - use cast<> instead of dyn_cast<> to avoid dereference of nullptr

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

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

[clang-tidy] RedundantControlFlowCheck::issueDiagnostic - use cast<> instead of dyn_cast<> to avoid dereference of nullptr

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

[clang-tidy] FunctionASTVisitor::TraverseStmt - use cast<> instead of dyn_cast<> to avoid dereference of nullptr

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

[clang-tidy] NoexceptMoveConstructorCheck::check - use castAs<> instead of getAs<> to avoid dereference of nullptr

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

[clang-tidy] UseNoexceptCheck::check - use cast<> instead of dyn_cast<> to avoid dereference of nullptr

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

The pointer is always dereferenced

[clang-tidy] ProBoundsConstantArrayIndexCheck::check - use cast<> instead of dyn_cast<> to avoid dereference of nullptr

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

[clang-tidy] checkOverridingFunctionReturnType - use castAs<> instead of getAs<> to avoid dereference of nullptr

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

Revert "Reland "[lld/coff] Make lld-link work in a non-MSVC shell, add /winsysroot:""

This reverts commit 0574b5fc and 73e585e4.

This change is causing the test Driver/cl-options.c to fail on Windows buildbots.
https://lab.llvm.org/staging/#/builders/204/builds/1343

A LUI instruction with flag RISCVII::MO_HI is usually used in conjunction
with ADDI, and jointly complete address computation. To bind the cost
evaluation of address computation, the LUI should not be regarded as a cheap
 move separately, which is consistent with ADDI.

In this test case, it improves the unroll-loop code that the rematerialization
of array's base address miss MachineCSE with Heuristics #1 at isProfitableToCSE.

Reviewed By: asb, frasercrmck

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

Reviewed By: asb, frasercrmck

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

By unsetting this property, we are now able to internalize more symbols
during LTO. I compared the output of `-save-temps` for both LLD and
ld64, and we now match ld64's behavior as far as `lto-internalize.ll` is
concerned.

(Thanks @smeenai for working on an initial version of this diff!)

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

Reviewed By: #lld-macho, thakis

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

Implements ADDS/SUBS 24-bit immediate optimization using the
MIPeepholeOpt pass. This follows the pattern:

Optimize ([adds|subs] r, imm) -> ([ADDS|SUBS] ([ADD|SUB] r, #imm0, lsl #12), #imm1),
if imm == (imm0<<12)+imm1. and both imm0 and imm1 are non-zero 12-bit unsigned
integers.

Optimize ([adds|subs] r, imm) -> ([SUBS|ADDS] ([SUB|ADD] r, #imm0, lsl #12), #imm1),
if imm == -(imm0<<12)-imm1, and both imm0 and imm1 are non-zero 12-bit unsigned
integers.

The SplitAndOpcFunc type had to change the return type to an Opcode pair so that
the first add/sub is the regular instruction and the second is the flag setting
instruction. This required updating the code in the AND case.

Testing:

I ran a two stage bootstrap with this code.
Using the second stage compiler, I verified that the negation of an ADDS to SUBS
or vice versa is a valid optimization. Example V == -0x111111.

Reviewed By: dmgreen

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

Move some combine patterns to DAG combine，and
it dealt with fixme left in RISCVInstrInfoZb.td.

Reviewed By: craig.topper

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

Reviewed By: browneee

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

It is generally an error when a USE-associated name clashes
with a name defined locally, but not in all cases; a generic
interface can be both USE-associated and locally defined.
This works, but not when there is also a local subprogram
with the same name, which is valid when that subprogram is
a specific of the local generic.  A bogus error issues at
the point of the USE because name resolution will have already
defined a symbol for the local subprogram.

The solution is to collect the names of local generics when
creating the program tree, and then create their symbols as
well if their names are also local subprograms, prior to any
USE association processing.

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

We are just grouping the files and the tests together.

Reviewed By: int3, #lld-macho

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

This diff has the C-string literals printed into the mapfile in the symbol table like how ld64 does.

Here is what ld64's mapfile looks like with C-string literals:
```
# Path: out
# Arch: x86_64
# Object files:
[  0] linker synthesized
[  1] foo.o
# Sections:
# Address       Size            Segment Section
0x100003F7D     0x0000001D      __TEXT  __text
0x100003F9A     0x0000001E      __TEXT  __cstring
0x100003FB8     0x00000048      __TEXT  __unwind_info
# Symbols:
# Address       Size            File  Name
0x100003F7D     0x0000001D      [  1] _main
0x100003F9A     0x0000000E      [  1] literal string: Hello world!\n
0x100003FA8     0x00000010      [  1] literal string: Hello, it's me\n
0x100003FB8     0x00000048      [  0] compact unwind info
```

Here is what the new lld's Mach-O mapfile looks like:
```
# Path: /Users/rgr/local/llvm-project/build/Debug/tools/lld/test/MachO/Output/map-file.s.tmp/c-string-liter
al-out
# Arch: x86_64
# Object files:
[  0] linker synthes...

Reviewed By: eugenis

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

Reviewed By: eugenis

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

The __kmp_hidden_helper_threads_num set to N+1 if user requested N threads.
Thus number of worker hidden helper threads corresponds to user request,
main thread of helper team excluded as it does not participate in actual work.
This also fixes divide-by-0 issue in the code.

Fixes #48656

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

When a scope's symbol has characteriztics whose specification
expressions depend on other non-constant symbols in the same scope,
f18 rightfully emits an error.  However, in the case of usage in
specification expressions involving host association, the program is not
invalid.  This can arise, for example, in the case of an internal
function whose result's attributes use host-associated variables.

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

This reverts commit 0d9b9152.

This change broke LLDB's build. I will need to recommit after fixing LLDB.

There are several checks in the runtime routine for the RESHAPE
intrinsic.  Some checks verify things that should have been checked at
compile time while others represent user errors.

This update changes the checks for user errors into calls to "Crash"
which include information about the failing check.  This identifies them
as user errors rather than compiler errors.

I also verified that the checks that remain as internal errors are also
checked by the front end.  I added a test to the front end's RESHAPE
test to complete the checks.

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

Despite the comment saying `[[no_unique_address]]` on the `__base_` data member
makes clang crash, this does not seem to be true on CI. So, mark `__base_` with
`_LIBCPP_NO_UNIQUE_ADDRESS`.

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

Use the dyld_shared_cache_(un)pin_mapping SPI to map the whole shared
cache in memory (if possible) to avoid repeated calls to mmap.

rdar://81189015

This fixes Linux musl build after D118423.

- add some test cases for `cbegin`/`cend`;
- make class definitions generally follow the order in which they are
  used;
- add a missing include.

Reviewed By: philnik

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

This ensures that if we have a dbg.addr in a coroutine funclet that is on one of
our function arguments, that the dbg.addr is not mapped to undef and also that
later it isn't hoisted to the front of the basic block. Instead it remains at
its original cloned location.

rdar://83957028

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

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

Recently we observed high memory pressure caused by clang during some parallel builds.
We discovered that we have several projects that have a large number of #define directives
in their TUs (on the order of millions), which caused huge memory consumption in clang due
to a lot of allocations for MacroInfo. We would like to reduce the memory overhead of
clang for a single #define to reduce the memory overhead for these files, to allow us to
reduce the memory pressure on the system during highly parallel builds. This change achieves
that by removing the SmallVector in MacroInfo and instead storing the tokens in an array
allocated using the bump pointer allocator, after all tokens are lexed.

The added unit test with 1000000 #define directives illustrates the problem. Prior to this
change, on arm64 macOS, clang's PP bump pointer allocator allocated 272007616 bytes, and
used roughly 272 bytes per #define. After this change, clang's PP bump pointer allocator
allocates 120002016 bytes, and uses only roughly 120 bytes per #define.

For an example test file that we have internally with 7.8 million #define directives, this
change produces the following improvement on arm64 macOS: Persistent allocation footprint for
this test case file as it's being compiled to LLVM IR went down 22% from 5.28 GB to 4.07 GB
and the total allocations went down 14% from 8.26 GB to 7.05 GB. Furthermore, this change
reduced the total number of allocations made by the system for this clang invocation from
1454853 to 133663, an order of magnitude improvement.

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