[NVPTX] Support 32-bit size operand for st.bulk (#217703)
PTX ISA 9.0 extends the `st.bulk` instruction to accept a 32-bit `size`
operand.
Add `i32` variants of the generic and `.shared::cta` NVVM intrinsics and
select them to `st.bulk` instructions using 32-bit registers. The new
patterns require PTX ISA 9.0 and `sm_100`.
The existing intrinsics continue to represent the original 64-bit forms.
Add code-generation coverage for both the default and short-pointer
ABIs.
zpool-prefetch: Fix document description typo
Verb should be imperative mood matching rest of manual.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Alexander Ziaee <ziaee at FreeBSD.org>
Closes #19184
[GVN] Decouple GVNValueTable and GVNPass (NFC)
This is a first patch in series with the ultimate goal to move `GVNPass`
out of `GVN.h` and into `GVN.cpp.`
This is not straightforward because because of the rather tangled
dependencies between `GVNPass`, `GVNHoistPass`, `ValueTable`,
and `LeaderMap`.
The `GVNHoistPass` pass references `GVNPass::ValueTable`, by peeking
into `GVNPass`, resp. including `GVN.h`. Since `GVNHoistPass` does not
actually depend on `GVNPass` itself, but only on the `ValueTable` it
contains, it would make more sense to move `ValueTable` out of `GVN.h`
to its own header file, to be included by both `GVN.h` and
`GVNHoist.cpp.`
That's not entirely straightforward either since `ValueTable` has
several member functions taking a `GVNPass` reference as an argument.
This prevents moving `GVNPass` out of `GVN.h` and into an anonymous
[9 lines not shown]
[GVN] Move `ValueTable` out of `GVN.h` (NFC)
* Rename `GVNPass::ValueTable` to `GVNValueTable`, and move it out to
the `llvm` namepace and to its own file `GVNValueTable.h`
* Move `GVNPass::Expression` into `llvm::GVNValueTable`.
* Move `GVNHoistPass` and `GVNSinkPass` to their own headers.
With these changes `GVHoist.cpp` and `GVNSink.cpp` no longer need
to include `GVN.h` or peek into `GVNPass` internals.
zfs_domount: fix vfs_t double-free on root setup failure
When zfs_root() or d_make_root() fails, zfs_domount() calls
zfs_umount(), which frees zfsvfs->z_vfs via zfsvfs_free(). After
the vfs_t lifetime was matched to fs_context, that vfs_t is still
owned by the caller in fc->fs_private. zpl_get_tree() then returns
without clearing fs_private, and put_fs_context() frees it again.
Detach z_vfs before zfs_umount() so the caller retains ownership,
matching the other zfs_domount() error paths.
This is a follow-up to the vfs_t lifetime change in #18377.
Reviewed-by: Rob Norris <rob.norris at truenas.com>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Wale Zhang <wale.zhang.ftd at gmail.com>
Closes #19167
[SandboxIR] Fix Value::stripAndAccumulateConstantOffsets (#225980)
The original test was not exercising the ExternalAnalysis FnRef, and we
we are passing a non-nullptr lambda even if the user has passed a
nullptr, which would cause a crash.
This patch fixes it.
Linux: read the snapshot creation time from its bonus buffer
When a '.zfs/snapshot/<name>' entry is looked up by name (stat, open, or
a path walk through it; listing the directory does not do this),
zfsctl_inode_lookup() reads the snapshot's creation time for the
entry's btime through dsl_dataset_hold_obj(). That instantiates the
whole in-core dataset (dsl_dir hold, deadlists, neighbour references,
fsid uniqueness) and tears it down again on release, and it accounts
for most of a dentry-cold lookup. The value is a field of the
snapshot's dsl_dataset_phys_t, so read it from the bonus buffer the way
the fsid is read, through a helper both callers share.
Same value, same locking, same fallback on error. A warm lookup is
unchanged; a cold one loses the dataset instantiation, roughly an order
of magnitude on the systems it was measured on.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Rob Norris <rob.norris at truenas.com>
Signed-off-by: Ameer Hamza <ameer.hamza at truenas.com>
Closes #19174
Linux: report a snapshot's fsid from its .zfs/snapshot entry
statfs() on a control directory inode ('.zfs', '.zfs/snapshot', or an
unmounted snapshot entry reached without the automount) fails with EIO
because zfs_statvfs() verifies the znode's SA handle, which these inodes
lack. Handle them explicitly: '.zfs' and '.zfs/snapshot' report the
containing filesystem, and a '.zfs/snapshot/<name>' entry reports the
fsid of its snapshot, read from the dataset's bonus buffer (the objset id
is encoded in the entry's inode number) without instantiating the
dataset, so a probe costs a few microseconds.
This identifies a snapshot without mounting it: open the entry with
O_PATH, which does not trigger the automount, and fstatfs() it. The
value is what the snapshot's superblock reports once mounted, and path
based statfs() still automounts as before. An NFS server resolving a
file handle for an unmounted snapshot (expired, or imported on another
node) can probe entries instead of mounting every snapshot until one
matches. Add the statfs_nomount helper, the snapdir_statfs_fsid test
and a zfsconcepts(7) note.
[5 lines not shown]
[OpenMP] Fix OpenMP reduction segfault with non-copyable types and user initializers. (#219265)
OpenMP custom reductions with user-defined initializers segfault when
the reduction variable type is non-copyable and has non-trivial members
(e.g., std::string). `Clang` was emitting only the user initializer
function call, leaving non-trivial
members uninitialized with garbage values, causing segfaults when those
members are accessed or assigned.
See https://godbolt.org/z/bboqKbhsT
This patch fixes the issue.
[RISCV][TableGen] Return instruction size from isCompressibleInst (#225660)
Not all compress patterns compress to a 2 byte instruction. There are a
few `Xqci` instructions that compress from a 6 byte instruction to a 4
byte instruction. Having `isCompressibleInst` optionally return the size
of the compressed instruction will help us better estimate instruction
sizes.
Assisted by gpt-5.6-luna
zpool: accept more redundant special and dedup vdevs
The replication check required a special or dedup vdev to tolerate
exactly as many device failures as the normal vdevs in the pool. A
3-way mirror special vdev on a raidz1 pool, or on a 2-way mirror pool,
was rejected as a mismatch, and the only way past it was -f, which
also overrides unrelated checks.
Accept a special or dedup vdev which tolerates at least as many
failures as the normal vdevs of a redundant pool. Special and dedup
vdevs are now compared with the normal vdevs rather than with whichever
vdev happens to precede them, so normal vdevs are still required to
match each other. Less redundant special or dedup vdevs, and redundant
ones added to a non-redundant pool, are still rejected.
As a side effect, a pool that already has a more redundant special
vdev is now considered consistent, so later additions to it are
checked instead of being skipped.
[4 lines not shown]
[libc++] Re-apply "Build GoogleBenchmark directly from Lit" (#225856)
Previously, we would build GoogleBenchmark against the just-built
library, not against the library being tested. When testing historical
versions of libc++ or other standard libraries, this breaks. So instead
of building Google Benchmark against the just-built library in CMake, do
it from Lit as part of the test suite's configuration.
I'm not a huge fan of using Lit as a poor man's build system and we
should make the CMake test suite self-contained, however this is a step
in the right direction and it removes a major coupling between the test
suite and the regular libc++ build.
This patch re-applies 1bfe9893f3dc which was reverted in 62ea87e542c3
because it broke the Fuchsia bots. This new version of the patch also
threads through the path to the CMake program being used, the CMake
generator and the CMake "make program" from the top-level CMake to the
test-suite, so that the Google Benchmark build can inherit what the
top-level CMake is using.
pkg: Check for Berkeley DB RPM database format
Commit 0d5bb1d010 added a check to silence warnings when building
on Debian systems where the /var/lib/rpm/rpmdb.sqlite RPM database
does not exist. However, RHEL8 still uses the older Berkeley DB
RPM database format, not SQLite, and the primary database file is
instead named /var/lib/rpm/Packages. Setting an the alternate,
empty RPM_DBPATH results in the package build failing due to missing
build dependencies. Resolve the build failure by additionally
checking for the legacy primary database name.
Reviewed-by: Tony Hutter <hutter2 at llnl.gov>
Reviewed-by: Glenn Washburn <development at efficientek.com>
Signed-off-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Closes #19181
[mlir-c] Add mlirOperationIsAncestor and mlirOperationIsProperAncestor (#206556)
Exposes `Operation::isAncestor` and `Operation::isProperAncestor` through the MLIR C API.
Assisted by: Claude
gzip: Update to 1.15
* Noteworthy changes in release 1.15 (2026-09-20) [stable]
** Bug fixes
gzip no longer can mistakenly remove the wrong file if some other
process simultaneously renames a gzip destination's ancestor.
[bug present since the beginning]
gzip -d no longer rejects PKZIP signatures, local header, and data
descriptors. These can appear in well-formed streamed zip files.
[bug present since the beginning]
gzip diagnostics now quote file names containing unusual characters.
[bug present since the beginning]
A use of uninitialized memory on some malformed inputs has been fixed.
[bug present since the beginning]
[44 lines not shown]
llvm-reduce: Error on -j with MIR inputs
Parallel chunk processing distributes work by serializing the program to
bitcode and reparsing it in each worker thread. Bitcode cannot represent
MachineFunctions, so readBitcode leaves ReducerWorkItem::MMI null and the
reparsed item reports isMIR() == false. The delta pass list is still the
MIR one, chosen from the original program, so the worker runs a MIR pass
over an item with no MachineModuleInfo and dereferences null.
This broke every MIR reduction using -j > 1, though not immediately: the
parallel path is only taken once there is more than one chunk left to
process, so the crash appeared after the first granularity increase.
Reject the combination up front instead of crashing partway through a
reduction. Supporting it would mean exchanging MIR text rather than
bitcode, and giving each worker its own TargetMachine.
Co-Authored-By: Claude Opus 5 <noreply at anthropic.com>
