This reverts commit dec63221d56e8092557f29f1f2c127828d7521bb.
This probably needs more discussion before we can land it. The consensus
(from what I can gather) in https://discourse.llvm.org/t/rfc-clang-format-all-the-things/76614
is that we should be careful with version upgrades for consistency.
This reverts commit c69ec700adec315b3daa55742f2ef655242fa297, which has been
obsolete since commit dec63221d56e because the clang-format style was added
in version 18.
Various (in-tree as well as downstream) targets currently depend on
`InliningUtils.h` to avoid circular dependencies. E.g. `TransformUtils`
depends on `ArithDialect`, so `ArithDialect` can't depend on
`TransformUtils` exporting `InliningUtils.h`. This change exposes that
header and it's implementation as a separate target. Having targets that
implement all the declared functions is the preferred approach for bazel
build graphs.
See also PR #84878, which moves the interface definitions to a separate
file in the `Interfaces` directory. This turned out to be controversial
and putting it in a different directory didn't seem to have any support
either. Instead, this PR only changes the bazel build without moving any
C++ code.
This fixes the case shown by
https://github.com/llvm/llvm-project/issues/64808#issuecomment-1929131611.
Similar to
f9caa12328,
we have some calls to constraint checking for a lambda's conversion
function while determining the conversion sequence.
This patch addresses the problem where the requires-expression within
such a lambda references to a Decl outside of the lambda by adding these
Decls to the current instantiation scope.
I'm abusing the flag `ForOverloadResolution` of
CheckFunctionConstraints, which is actually meant to consider the Decls
from parent DeclContexts.
---------
Co-authored-by: cor3ntin <corentinjabot@gmail.com>
Some targets have passes with parameters, e.g. ARM, AMDGPU and MIPS.
For example, AMDGPU has a pass `AMDGPUAtomicOptimizerPass`
which need a `ScanOption`, this commit enables the syntax
like `-passes=amdgpu-atomic-optimizer<strategy=dpp>` for backend passes.
Buffers are no longer deallocation by One-Shot Bufferize. This is now
done by a separate buffer deallocation pass.
Also fix a bug in the `vector.mask` folding, which was triggered by
`-buffer-deallocation-pipeline`, which runs the canonicalizer.
This PR adds promised interface declarations for all interfaces declared
in `InitAllDialects.h`.
Promised interfaces allow a dialect to declare that it will have an
implementation of a particular interface, crashing the program if one
isn't provided when the interface is used.
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.
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);
^
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 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 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>
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 92a09c0165b87032e1bd05020a78ed845cf35661.
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.
