When the debug info refers to a dwo with relative `DW_AT_comp_dir` and
`DW_AT_dwo_name`, we only print the `DW_AT_comp_dir` in our error
message if we can't find it. This often isn't very helpful, especially
when the `DW_AT_comp_dir` is ".":
```
(lldb) fr v
error: unable to locate .dwo debug file "." for skeleton DIE 0x000000000000003c
```
I'm updating the error message to include both `DW_AT_comp_dir` (if it
exists) and `DW_AT_dwo_name` when the `DW_AT_dwo_name` is relative. The
behavior when `DW_AT_dwo_name` is absolute should be the same.
There still seem to be issues with the files changed step taking a
significant amount of time on PRs. This seems to be occurring on PRs
with one commit and not on PRs with more than one commit which is why I
didn't catch this nuance before. Either way, fetching an additional
commit seems to fix the issue. Requires a little bit of hackiness due to
the fact that you can't do math in the github actions variables.
Will be monitoring this over the next little bit to see if this actually
fixes the problem.
CI stuff is annoying sometimes.
This patch adds a step to build the lldb docs when they change to the
Github docs action, enabling easy triage of warnings/docs build failures
during the PR process.
This patch adds the clang-tools-extra docs to the Github CI job that
builds docs, enabling the ability to easily ensure the docs build
properly without warnings in PRs and at the tip of tree.
The patch contains a basic BumpAllocator for (AMD)GPUs to allow us to
run more tests. The allocator implements `malloc`, both internally and
externally, while we continue to default to the NVIDIA `malloc` when we
target NVIDIA GPUs. Once we have smarter or customizable allocators we
should consider this choice, for now, this allocator is better than
none. It traps if it is out of memory, making it easy to debug. Heap
size is configured via `LIBOMPTARGET_HEAP_SIZE` and defaults to 512MB.
It allows to track allocation statistics via
`LIBOMPTARGET_DEVICE_RTL_DEBUG=8` (together with
`-fopenmp-target-debug=8`). Two tests were added, and one was enabled.
This is the next step towards fixing
https://github.com/llvm/llvm-project/issues/66708
Reductions with intermediate stores currently need to be fixed in order
of their intermediate stores. Instead of doing this at fixup time after
code has been generated, sort the reductions in adjustRecipesForReductions.
This makes the order explicit in VPlan and will enable removing
fixReductions with modeling computing the final reduction result in
VPlan, followed by also modeling the intermediate stores explicitly.
In mingw mode, all linker paths are passed explicitly to the linker
by the compiler driver. Don't try to implicitly add linker paths
from the LIB environment variable or by detecting an MSVC
installation directory.
If the /winsysroot command line parameter is explicitly passed to
lld-link while /lldmingw is specified, it could be considered reasonable
to actually include those paths. However, modifying the code to
handle only the /winsysroot case but not the other ones, when the
mingw mode has been enabled, seems like much more code complexity
for a mostly hypothetical case.
Add a test for this when case when using LIB. (The code paths for
trying to detect an MSVC installation aren't really regression tested.)
Also fix an issue in the existing test for "Check that when /winsysroot
is specified, %LIB% is ignored.", where the LIB variable pointed
to a nonexistent directory, so the test would pass even if /winsysroot
wouldn't be specified.
Reland this after https://github.com/llvm/llvm-project/pull/68077 and
https://github.com/llvm/llvm-project/pull/69781 - the compiler-rt test
that used -lldmingw in MSVC environments has been updated to use a more
specific option.
Differential Revision: https://reviews.llvm.org/D144084
If a potential interfering access is in a different kernel and the
underlying object has kernel lifetime we can straight out ignore the
interfering access.
TODO: This should be made much stronger via "reaching kernels", which we
already track in AAKernelInfo.
Before target.xml, lldb had its own method for querying the remote stub
of the registers it supports, qRegisterInfo. The gdb standard method of
using a target.xml file to describe the available registers has become
commonplace, and the lldb method for doing this is no longer needed.
Stubs should describe their registers to lldb, but it should be with the
target.xml file.
This allows git-clang-format to be used on a Windows terminal without
manually needing to find the path and invoke the python interpreter. We
have a similar script for `scan-build`.
Fixes#69643
GCC defines this macro for how many single-precision floating point registers
can be used.
If the -mno-odd-spreg option is given, it will be 16; if either -mno-odd-spreg
nor -modd-spreg are given, we set it to 16 for FPXX.
Reviewed By: theraven
Differential Revision: https://reviews.llvm.org/D157896
The SPHINX_OUTPUT_HTML and SPHINX_OUTPUT_MAN CMake flags are by default
set to ON/True in ./llvm/cmake/modules/FindSphinx.cmake, so we don't
need to set them true again within the CMake invocation.
Follow up fix for #68786 to address that MachineFunction handleInsertion
is actually called before a new instruction has been inserted into the
block. Hence new instructions must be recorded and SlotIndex updates
performed after the delegate call.
Prefer the new flag -lld-allow-duplicate-weak (which was added recently
in a67ae8c0fd), over the old -lldmingw.
The -lldmingw option enables a number of different behaviours, while
this test only is interested in one aspect of them.
This should allow making -lldmingw more strict with not enabling MSVC
specific behaviours like inferring lib directories automatically from
the environment, as being pursued in https://reviews.llvm.org/D144084.
When the user specifies `LIBCXX_HARDENING_MODE` on the command line in a
bootstrapping build, it should override the setting implied by
`LLVM_ENABLE_ASSERTIONS`.
This patch fixes:
compiler-rt/lib/builtins/int_to_fp_impl.inc:22:18: error: expression
is not an integer constant expression; folding it to a constant is a
GNU extension [-Werror,-Wgnu-folding-constant]
by using enum for constants.
When this file is included in a project compiled with GCC 13 `-Werror`,
compilation fails with the following diagnostic:
<pre>
/usr/lib/llvm-17.0/include/clang/AST/TypeLoc.h: In constructor
'clang::TypeSourceInfo::TypeSourceInfo(clang::QualType, size_t)':
/usr/lib/llvm-17.0/include/clang/AST/TypeLoc.h:245:9: error: 'void*
memset(void*, int, size_t)' clearing an object of non-trivial type
'class clang::TypeSourceInfo'; use assignment instead
[-Werror=class-memaccess]
245 | memset(this + 1, 0, DataSize);
| ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~
</pre>
To avoid this, we add an explicit type cast. The cast to `void*` makes
sense, since other member functions of `TypeSourceInfo` also treat the
buffer `(this + 1)` of length `DataSize` as opaque memory, and was
likely left out by mistake.
Fixes: 4498663f3d ("[AST] Initialized data after TypeSourceInfo")
I also suggest to apply this to release/17.x if possible.
If we update the state, or indicate a pessimistic fixpoint, we need to
consider NestedParallelism too.
Fixes part of https://github.com/llvm/llvm-project/issues/66708
That said, the reproducer still needs malloc which we don't support on
AMD GPU. Will be added later.
The underlying timezone classes are being reimplemented in Swift, and these
strings will be Swift strings, without the ObjC `@` prefix. Leaving off the `@`
makes these tests usable both before and after the reimplmentation of
Foundation in Swift.
This patches changes the docs action to run a fetch with a depth of the
number of commits in the PR (1 if we're just running against a push
event) which significantly increases the speed of the changed files
event. The changed files event goes from taking ~30m to ~3s without any
noticeable increase in fetch time.
Fixes https://github.com/llvm/llvm-project/issues/69730 (also see
https://reviews.llvm.org/D155543).
There are two things outstanding (why I didn't land before):
1. add some C API tests for `mlirOperationWalk`;
2. potentially refactor how the invalidation in `run` works; the first
version of the code looked like this:
```cpp
if (invalidateOps) {
auto *context = op.getOperation().getContext().get();
MlirOperationWalkCallback invalidatingCallback =
[](MlirOperation op, void *userData) {
PyMlirContext *context =
static_cast<PyMlirContext *>(userData);
context->setOperationInvalid(op);
};
auto numRegions =
mlirOperationGetNumRegions(op.getOperation().get());
for (int i = 0; i < numRegions; ++i) {
MlirRegion region =
mlirOperationGetRegion(op.getOperation().get(), i);
for (MlirBlock block = mlirRegionGetFirstBlock(region);
!mlirBlockIsNull(block);
block = mlirBlockGetNextInRegion(block))
for (MlirOperation childOp =
mlirBlockGetFirstOperation(block);
!mlirOperationIsNull(childOp);
childOp = mlirOperationGetNextInBlock(childOp))
mlirOperationWalk(childOp, invalidatingCallback, context,
MlirWalkPostOrder);
}
}
```
This is verbose and ugly but it has the important benefit of not
executing `mlirOperationEqual(rootOp->get(), op)` for every op
underneath the root op.
Supposing there's no desire for the slightly more efficient but highly
convoluted approach, I can land this "posthaste".
But, since we have eyes on this now, any suggestions or approaches (or
needs/concerns) are welcome.
Try to transform the powi(X, Y) / X into powi(X, Y-1) with Ofast.
For this case, when the Y is 3, then powi(X, 2) is replaced by X * X in
the further step.
Fixes https://github.com/llvm/llvm-project/pull/67216
Reviewed By: dtcxzyw, nikic, jcranmer-intel
Forward assignValueToReg to the base class to make the copy. Add
markPhysRegUsed to contain the differences between call handling and
argument handling. Introduce RISCVFormalArgHandler.
This structure matches how AArch64, AMDGPU, and X86 are structured.
I've also added `MIRBuilder.getMRI()->addLiveIn(PhysReg);` to match the
other targets.
