[lldb] Run the LLDB test suite under MTE on capable Apple HW (#185780)
This PR adds support for running the LLDB test suite under MTE. It's
enabled by default on capable hardware when asserts are enabled. It
relies on a launcher (#185921) which launches the process with the
appropriate posix_spawn attribute. One thing worth noting here is that
child processes inherit the MTE property, so binaries launched by the
test suite in this mode also run under MTE.
Besides the logic to detect the default and thread through the launcher,
I also had to make a small change to LLVM LIT's `ToolSubst` class to
support an optional launcher for the shell tests.
[mlir][DataFlow] Fix crash in TestLastModifiedPass for unreachable private functions (#186160)
TestLastModifiedPass asserted that a dense lattice state is always
present after running the data flow solver. However, in interprocedural
analysis mode (the default), private functions that are never called
from any callee in the module are not analyzed, so no lattice state is
computed for their program points.
Replace the assertion with a null check that prints "<not computed>"
when the lattice state is absent. This matches the expected behavior:
unreachable code in interprocedural mode simply has no computed analysis
result.
Add a regression test for the case where a tagged op is inside an
unreachable private function.
Fixes #128333
Assisted-by: Claude Code
contrib/debian: add zilstat.1 manpage to installation list
Missed in 65165df129, which caused Debian packaging to fail.
Sponsored-by: TrueNAS
Reviewed-by: Ameer Hamza <ahamza at ixsystems.com>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18313
[mlir] Fix assert in TestWrittenToPass for unreachable private functions (#186162)
TestSparseBackwardDataFlowAnalysis::TestWrittenToPass asserted that the
WrittenTo sparse lattice was always computed for tagged operands and
results. This assertion fires when analyzing a private function that is
never called from anywhere: in interprocedural mode the backward data
flow solver does not visit such dead code, leaving the lattice state
uninitialized.
Replace the assertions with null checks that print "<not computed>"
instead, matching the approach used in TestDenseForwardDataFlowAnalysis
for the analogous dense forward case.
Fixes #128339
Assisted-by: Claude Code
fusefs: redo vnode attribute locking
Previously most fields in fuse_vnode_data were protected by the vnode
lock. But because DEBUG_VFS_LOCKS was never enabled by default until
stable/15 the assertions were never checked, and many were wrong.
Others were missing. This led to panics in stable/15 and 16.0-CURRENT,
when a vnode was expected to be exclusively locked but wasn't, for fuse
file systems that mount with "-o async".
In some places it isn't possible to exclusively lock the vnode when
accessing these fields. So protect them with a new mutex instead. This
fixes panics and unprotected field accesses in VOP_READ,
VOP_COPY_FILE_RANGE, VOP_GETATTR, VOP_BMAP, and FUSE_NOTIFY_INVAL_ENTRY.
Add assertions everywhere the protected fields are accessed.
Lock the vnode exclusively when handling FUSE_NOTIFY_INVAL_INODE.
During fuse_vnode_setsize, if the vnode isn't already exclusively
locked, use the vn_delayed_setsize mechanism. This fixes panics during
[13 lines not shown]
[TargetParser] Introduce AMDGPUTargetParser.def. NFCI. (#186137)
Define AMDGPU GPUs in a separate .def file similar to other targets, so
they are listed in just one place instead of three.
[openmp] Add support for Arm64X to libomp
This patch allows building libomp.dll and libomp.lib as Arm64X binaries
containing both arm64 and arm64ec code and useable from applications
compiled for both architectures.
[openmp] Add support for arm64ec to libomp
This patch adds arm64ec support to libomp.
Note that this support isn't entirely usable on Windows hosts as libomp
requires LLVM_PER_TARGET_RUNTIME_DIR=On for to work correctly when
multiple runtimes are built, which is unsupported on Windows. A
following patch will add arm64x support to the build to rectify this.
[mlir][ArithToSPIRV] Fix uitofp/sitofp for emulated narrow integer types (#186136)
When a SPIR-V target lacks Int8/Int16 capabilities, narrow integers are
emulated as i32. The upper bits of the i32 container may contain garbage
(e.g., sign-extended bits from packed byte extraction).
Previously, arith.uitofp and arith.sitofp on these emulated types would
use the generic TypeCastingOpPattern, which either forwards the operand
unchanged (when src/dst types match after conversion) or creates a plain
spirv.ConvertUToF/ConvertSToF without cleaning the upper bits. This
produces incorrect results.
This was exposed by arith canonicalization patterns (UIToFPOfExtUI,
SIToFPOfExtSI) that fold uitofp(extui(x)) -> uitofp(x) and
sitofp(extsi(x)) -> sitofp(x), eliminating the ext operations which were
incidentally cleaning the upper bits.
Replace TypeCastingOpPattern for UIToFP/SIToFP with IntToFPPattern, a
single template parameterized on signedness that handles both widening
[7 lines not shown]
