This change lifts the restriction that purely allocated empty sparse
tensors cannot escape the method. Instead it makes a best effort to add
a finalizing operation before the escape.

This assumes that
(1) we never build sparse tensors across method boundaries
    (e.g. allocate in one, insert in other method)
(2) if we have other uses of the empty allocation in the
    same method, we assume that either that op will fail
    or will do the finalization for us.

This is best-effort, but fixes some very obvious missing cases.

Since LLVM supports `-ffat-lto-objects` we should enable this as an
option in the LLVM build. FatLTO should improve the time it takes to
build tests for LTO enabled builds of the compiler by not linking w/ the
bitcode portion of the object files, which should speed up build times
for LTO builds without disabling optimizations.

llvm-project/mlir/lib/Target/LLVMIR/DebugTranslation.cpp:226:10:
error: unused variable '[iter, inserted]' [-Werror,-Wunused-variable]
    auto [iter, inserted] =
         ^
1 error generated.

Static local variables with dynamic initializers depend on implicitly defined
guard variables to synchronize thread-safe initialization.  These guard
variables may have external linkage and therefore require a stable name for
linkage purposes.  The Microsoft ABI assigns these variables a local name of
'$TSS' followed by a discriminator and mangles them as a static local variable
of type 'int'.  Previously, the '$TSS<discriminator>' portion of the name was
not registered as a back reference candidate and this resulted in incorrect
back references for enclosing class and/or namespace scopes that might be
referenced in the signature of the enclosing function.  This change adds the
previously missing back reference registration.  This matches the mangling
performed by MSVC and resolves incompatibilities when inline functions with
static local variables are inlined across DLL boundaries.

This is an ABI change and has the potential to cause backward compatibility
issues with previous Clang releases.

Fixes #83616

Move CCC_OVERRIDE_OPTIONS support to clangDriver so that it may be used outside of the 
clang driver binary.

The override functionality will be used in LLDB, to apply adjustments to ClangImporter 
flags. This will be useful as an escape hatch when there are issues that can be fixed 
by adding or removing clang flags.

The only thing changed is the name, from `ApplyQAOverride` to `applyOverrideOptions`.

`EvaluateExpression` does not always create a new persistent result. If the expression 
is a bare persistent variable, then a new persistent result is not created. This means 
the caller can't assume a new persistent result is created for each evaluation. 
However, `dwim-print` was doing exactly that: assuming a new persistent result for each 
evaluation. This resulted in a bug:

```
(lldb) p int $j = 23
(lldb) p $j
(lldb) p $j
```

The first `p $j` would not create a persistent result, and so `dwim-print` would 
inadvertently delete `$j`. The second `p $j` would fail.

The fix is to try `expr` as a persistent variable, after trying `expr` as a frame 
variable. For persistent variables, this avoids calling `EvaluateExpression`.

Resolves https://github.com/llvm/llvm-project/issues/84806

rdar://124688427

llvm-project/lldb/unittests/Host/AlarmTest.cpp:49:7:
error: 'lock_guard' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
      std::lock_guard guard(m);
      ^

llvm-project/lldb/source/Host/common/Alarm.cpp:37:5:
error: 'lock_guard' may not intend to support class template argument deduction [-Werror,-Wctad-maybe-unsupported]
    std::lock_guard alarm_guard(m_alarm_mutex);
    ^

Summary:
This documentation was lagging reality and didn't contain much. Update
it with some more information now that it's more mature.

Followup to #85188.

This PR adds `-march=generic` support for the NVPTX backend. This
fulfills a TODO introduced in #79873.

With this PR, users can explicitly request the "default" CUDA
architecture, which makes sure that no specific architecture is
specified.

This PR does not address any compatibility issues between different CUDA
versions.

---------

Co-authored-by: Joseph Huber <huberjn@outlook.com>

This is another step towards supporting DWARF5 checksums and inline
source code in LLDB.

Clean-up to keep the type qualifier next to the type.

Reviewers: klausler

Reviewed By: klausler

Pull Request: https://github.com/llvm/llvm-project/pull/85180

[Clause representation 6/6]

This is a simplified implementation of std::reference_wrapper that can be used
in the offload builds for the device code. The methods are properly
marked with RT_API_ATTRS so that the device compilation succedes.

Reviewers: jeanPerier, klausler

Reviewed By: jeanPerier

Pull Request: https://github.com/llvm/llvm-project/pull/85178

This reverts commit 8f0012d3.

The common-linkage.ll test fails with ptxas enabled.

This is a simplified implementation of std::optional that can be used
in the offload builds for the device code. The methods are properly
marked with RT_API_ATTRS so that the device compilation succedes.

Reviewers: klausler, jeanPerier

Reviewed By: jeanPerier

Pull Request: https://github.com/llvm/llvm-project/pull/85177

This defines the basic set of pointer authentication clang builtins
(provided in a new header, ptrauth.h), with diagnostics and IRGen
support.  The availability of the builtins is gated on a new flag,
`-fptrauth-intrinsics`.

Note that this only includes the basic intrinsics, and notably excludes
`ptrauth_sign_constant`, `ptrauth_type_discriminator`, and
`ptrauth_string_discriminator`, which need extra logic to be fully
supported.

This also introduces clang/docs/PointerAuthentication.rst, which
describes the ptrauth model in general, in addition to these builtins.

Co-Authored-By: Akira Hatanaka <ahatanaka@apple.com>
Co-Authored-By: John McCall <rjmccall@apple.com>

Accept and represent asterisks within the parenthesized grid and block
specification lists.

The maximum number of significant hexadecimal digits in EX0.0 REAL
output editing is 29, not 28. Fix by computing it at build time from the
precision of REAL(16).

This reverts commit 92a09c01.

This is triggering a bunch of new -Wnullability-completeness warnings
in code with existing raw pointer nullability annotations.

The intent was the new nullability locations wouldn't affect those
warnings, so this is a bug at least for now.

This adds support for DW_IDX_parent. If DIE has a parent then
DW_IDX_parent in Entry will point to Entry for that parent DIE.
Otherwise it will have DW_FORM_flag_present in abbrev. Which takes zero
space in Entry.

This came from

https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151

See https://github.com/llvm/llvm-project/issues/85283.

I had a test for `nextdownl` that was failing and I thought I should add
`nextupl` and `nextdownl` later and first make a PR for the other
functions.

cc @lntue

Fix bazel build after #80251.

This simply updates the rewrites to propagate the scalable flags (which
as they do not alter the vector shape, is pretty simple).

The added tests are simply scalable versions of the existing vector
tests.

…5025)"

This reverts commit 58ef9bec.

There is a bool to float casting issue that needs to be sorted out to
make sure this is target independent

Currently, we always show the argument passed to dsymForUUID in the
corresponding progress update. Most of the time this is a UUID, but it
can also be an absolute path. The former is pretty uninformative and the
latter needlessly noisy.

This changes the progress update to print the UUID and the module name,
if both are available. Otherwise, we print the UUID or the module name
depending on which one is available.

We now also unconditionally pass the module file spec and architecture
to DownloadObjectAndSymbolFile, while previously this was conditional on
the file existing on-disk. This should be harmless:

  - We already check that the file exists in DownloadObjectAndSymbolFile.
  - It doesn't make sense to check the filesystem for the architecutre.

rdar://124643548

When running OpenMP offloading application with LIBOMPTARGET_INFO=-1,
the addresses of the Copying data from **device** to **host**, the
address are swap.
As an example, Currently the address would be
```
omptarget device 0 info: Mapping exists with HstPtrBegin=0x00007ffddaf0fb90, TgtPtrBegin=0x00007fb385404000, Size=8000, DynRefCount=0 (decremented, delayed deletion), HoldRefCount=0
omptarget device 0 info: Copying data from device to host, TgtPtr=0x00007ffddaf0fb90, HstPtr=0x00007fb385404000, Size=8000, Name=d
```
And it should be
```
omptarget device 0 info: Copying data from device to host, TgtPtr=0x00007fb385404000, HstPtr=0x00007ffddaf0fb90, Size=8000, Name=d
```

---------

Co-authored-by: fel-cab <fel-cab@github.com>

Add support for dynamically sized alloca instructions with the PTX
alloca instruction introduced in PTX 7.3 
([9.7.15.3. Stack Manipulation Instructions: alloca]
(https://docs.nvidia.com/cuda/parallel-thread-execution/index.html#stack-manipulation-instructions-alloca))

This should make sure PRs like #84409 get labelled.

The plugin was not getting built as the build_generic_elf64 macro
assumes the LLVM triple processor name matches the CMake processor name,
which is unfortunately not the case for SystemZ.

Fix this by providing two separate arguments instead.

Actually building the plugin exposed a number of other issues causing
various test failures. Specifically, I've had to add the SystemZ target
to
- CompilerInvocation::ParseLangArgs
- linkDevice in ClangLinuxWrapper.cpp
- OMPContext::OMPContext (to set the device_kind_cpu trait)
- LIBOMPTARGET_ALL_TARGETS in libomptarget/CMakeLists.txt
- a check_plugin_target call in libomptarget/src/CMakeLists.txt

Finally, I've had to set a number of test cases to UNSUPPORTED on
s390x-ibm-linux-gnu; all these tests were already marked as UNSUPPORTED
for x86_64-pc-linux-gnu and aarch64-unknown-linux-gnu and are failing on
s390x for what seem to be the same reason.

In addition, this also requires support for BE ELF files in
plugins-nextgen: https://github.com/llvm/llvm-project/pull/85246

This matches other targets.

To match the entrypoints and types for baremetal, we need to include
__qsortrcompare_t and omit __atexithandler_t.

libc++ char_traits.h assumes EOF is always available

See #85158 for more details.

Only apply stale matching if the binary function is in CFG state, i.e.
has basic blocks.

Test Plan:
Updated bolt/test/X86/reader-stale-yaml.test