Currently variables appearing inside shared clause of OpenMP task construct
are not visible inside lldb debugger.

After the current patch, lldb is able to show the variable

```
* thread #1, name = 'a.out', stop reason = breakpoint 1.1
    frame #0: 0x0000000000400934 a.out`.omp_task_entry. [inlined] .omp_outlined.(.global_tid.=0, .part_id.=0x000000000071f0d0, .privates.=0x000000000071f0e8, .copy_fn.=(a.out`.omp_task_privates_map. at testshared.cxx:8), .task_t.=0x000000000071f0c0, __context=0x000000000071f0f0) at testshared.cxx:10:34
   7      else {
   8    #pragma omp task shared(svar) firstprivate(n)
   9        {
-> 10         printf("Task svar = %d\n", svar);
   11         printf("Task n = %d\n", n);
   12         svar = fib(n - 1);
   13       }
(lldb) p svar
(int) $0 = 9
```

Reviewed By: djtodoro

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

After D116148 the memccpy gets optimized away and the expected
uninitialized memory access does not occur.

Make sure the call does not get optimized away.

The paths to the compiler and to the python executable may need to
be quoted (if they're installed into e.g. C:\Program Files).

All testing commands that are executed expect a gcc compatible command
line interface, while clang-cl uses different command line options.
In the original testing config, if the chosen compiler was clang-cl, it
was replaced with clang++ by looking for such an executable in the path.

For the new from-scratch test configs, I instead chose to add
"--driver-mode=g++" to flags - invoking "clang-cl --driver-mode=g++"
has the same effect as invoking "clang++", without needing to run any
heuristics for picking a different compiler executable.

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

While there's little value in polishing the old config system,
I ran into this function and was confused for a while, while grepping
around and trying to wrap my head around things.

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

The test is currently marked XFAIL for mingw environments, but latest
mingw-w64 got support for timespec_get:
https://github.com/mingw-w64/mingw-w64/commit/e62a0a987c80f6a6fdac3e350943ae8085de0bd5

The CI environment will probably be upgraded to a state where this
test is passing only after 14.x is branched in the llvm-project monorepo.

If we'd just go from having an XFAIL to no marking at all (when CI is
passing), we'd have to update both main and 14.x branches in sync
exactly when the CI runners are updated to a newer version.

Instead, mark the test as temporarily unsupported (so it doesn't
cause failed builds when the CI environment is updated); after the
CI environments are upgraded to such a state, we can remove the
UNSUPPORTED marking to start requiring it to pass on the main branch,
without needing to synchronize that change to anything else.

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

This finishes the GetSupportedArchitectureAtIndex migration. There are
opportunities to simplify this even further, but I am going to leave
that to the platform owners.

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

By creating the header and latch blocks up front and adding blocks and
recipes in between those 2 blocks we ensure that the entry and exits of
the plan remain valid throughout construction.

In order to avoid test changes and keep printing of the plans the same,
we use the new header block instead of creating a new block on the first
iteration of the loop traversing the original loop.

We also fold the latch into its predecessor.

This is a follow up to a post-commit suggestion in D114586.

Reviewed By: Ayal

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

Follow-up suggested post-commit for 1a54889f.

This is similar to what we have already done to some other tests.
See D102643, D102710, D102754.

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

dwarfgen::Generator cannot be created if there is no asm backend for a
target. For example, if the default target triple is nvptx-nvidia-cuda,
some tests fail even after D98400, which added checks for most cases.
This patch extends the approach to the remaining cases.

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

If Generator::create() returns an error, tests should fail gracefully
and report the cause, for example:

[ RUN      ] DebugLineBasicFixture.ParserSkipsCorrectly
.../llvm/unittests/DebugInfo/DWARF/DWARFDebugLineTest.cpp:47: Failure
Value of: llvm::detail::TakeExpected(ExpectedGenerator)
Expected: succeeded
  Actual: failed  (no asm backend for target nvptx64-nvidia-cuda)

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

Mark the first function optnone as well, to make sure that the
test is independent of optimization.

As reames mentioned on related reviews, we don't need the nocapture
requirement here. First of all, from an API perspective, this is
not something that MemoryLocation::getForDest() should be checking
in the first place, because it does not affect which memory this
particular call can access; it's an orthogonal concern that should
be handled by the caller if necessary.

However, for both of the motivating users in DSE and InstCombine,
we don't need the nocapture requirement, because the capture can
either be purely local to the call (a pointer identity check that
is irrelevant to us), be part of the return value (which we check
is unused), or be written in the dest location, which we have
determined to be dead.

This allows us to remove the special handling for libcalls as well.

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

This are tests extracted from https://reviews.llvm.org/D110322, committed
prior to that patch to show the change in behavior.

This patch implements __builtin_reduce_xor as specified in D111529.

Reviewed By: fhahn, aaron.ballman

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

descriptor.h is using std::max, so it should include <algorithm>.

This should fix a build issue on Windows on Arm.

The old member was `= 0`:
https://github.com/llvm/llvm-project/commit/f5ac23b5ae090d64d31f0b6624470af97dc20bf6#diff-7781d63141d53242da0520361a554df579ecb079b33bdcfbe7a0db95d44cca49L1740

It looks like this caused some bots to fail:
https://lab.llvm.org/buildbot/#/builders/127/builds/21684

It is not necessary to explicitly check which attributes are
present, and only add those to the builder. We can simply list
all attributes that need to be stripped and remove them
unconditionally. This also allows us to use some nicer APIs that
don't require mucking about with attribute list indices.

We're only removing a single attribute, so there is no need to
go through AttrBuilder.

As we're only removing and adding a single attribute, there is no
need to go through AttrBuilder.

The areFunctionArgsABICompatible() hook currently accepts a list of
pointer arguments, though what we're actually interested in is the
ABI compatibility after these pointer arguments have been converted
into value arguments.

This means that a) the current API is incompatible with opaque
pointers (because it requires inspection of pointee types) and
b) it can only be used in the specific context of ArgPromotion.
I would like to reuse the API when inspecting calls during inlining.

This patch converts it into an areTypesABICompatible() hook, which
accepts a list of types. This makes the method more generally usable,
and compatible with opaque pointers from an API perspective (the
actual usage in ArgPromotion/Attributor is still incompatible,
I'll follow up on that in separate patches).

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

Version 2 of 'main bin spec' LC_NOTE allows for the specification
of a slide of where the binary is loaded in the corefile virtual
address space.  It also adds a (currently unused) platform field
for the main binary.

Some corefile creators will only have a UUID and an offset to be
applied to the binary.

Changed TestFirmwareCorefiles.py to test this new form of
'main bin spec' with a slide, and also to run on both x86_64
and arm64 macOS systems.

Differential Revision: https://reviews.llvm.org/D116094
rdar://85938455

According to the discussion in https://reviews.llvm.org/D110322 the code
that removes side effect from replaced function call is deleted.

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

This does not decrease sizeof(InputSection) (important for memory usage) on
ELF64 by itself but allows we to add another uint32_t.

This commit adds two test about template class instantiation in
transitively imported module. They are used as pre-commit tests for
successive patches.

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

Granularize the `<filesystem>` header

Reviewed By: Quuxplusone, ldionne, #libc

Spies: libcxx-commits, mgorny

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

Eliminate a bogus operator== overload.
Also, check more intermediate steps in the logic we're checking here.
Some of this simplification is possible only now that we've implemented
more of <ranges>.

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

See also: https://reviews.llvm.org/D111157

Move the handling of brace wrapping after => from unwrapped line
parser to token annotator and clean up the parser.

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

Extracted from D99484. My new plan is to start from the outside and work
inward.

Reviewed By: compnerd

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

Reland integrates build fixes & further review suggestions.

Thanks to @zturner for the initial S_OBJNAME patch!

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

Also revert all subsequent fixes:
- abd1cbf5 [Clang] Disable debug-info-objname.cpp test on Unix until I sort out the issue.
- 00ec4412 [Clang] debug-info-objname.cpp test: explictly encode a x86 target when using %clang_cl to avoid falling back to a native CPU triple.
- cd407f6e [Clang] Fix build by restricting debug-info-objname.cpp test to x86.