[X86] Replace custom AND/OR/XOR reduction pattern matching with ISD::VECREDUCE_AND/OR/XOR support (#199544)
The middle-end (SLP, VectorCombine and InstCombine) recognition and
handling of vector logic reduction patterns is sufficient now, so the
backend can work with ISD::VECREDUCE_AND/OR/XOR nodes directly.
[GVN] Track visited nodes in equality propagation to avoid OOM (#212265)
The added test ended up being out-of-memory (OOM) killed, because GVN
computed the same equality facts through exponentially many paths.
Co-authored-by: Katy Thackray <katy.thackray2 at arm.com>
[flang] Add an example plugin exercising the HLFIR pipeline extension points
The HLFIR extension points, the pipeline config callback registry and fir-opt's
symbol export all exist to let an out-of-tree MLIR pass run while the HLFIR
intrinsic operations (hlfir.sum, hlfir.matmul, ...) are still present. None of
that was covered end to end, and nothing showed how to use it.
Add flang/examples/HLFIRPipelinePlugin, modelled on PrintFlangFunctionNames. It
contributes a pass that prints the HLFIR operations still present in the module,
tagged with the pipeline position it was inserted at, and exposes it through
both plugin entry points: a static initializer calling
fir::registerPassPipelineConfigCallback for the `flang -fc1 -load` path, and
mlirGetPassPluginInfo so fir-opt can load it with --load-pass-plugin.
Nothing is linked into the shared object; MLIR, FIR and flang symbols resolve
against the host tool, which is what export_executable_symbols_for_plugins on
flang and fir-opt provides.
Two tests use it. Examples/hlfir-pipeline-plugin.f90 covers -emit-fir and
[7 lines not shown]
games/anki: Update to 26.08
* Switch to USES=npm and adjust/remove the relevant parts.
Although Yarn v4 is already being used according to "package.json",
stick with Yarn v1 for now to complete a 1:1 migration from the before
to the after state with respect to the used tools during build.
Changelog:
https://github.com/ankitects/anki/releases/tag/26.08
net/turnserver: Update 4.14.0 => 4.16.0
Port changes:
- Run turnserver as non-root by default.
- Pet port(lint|fmt|clippy).
PR: 297251, 296810
Reported by: Frank Wall <freebsd at moov.de>
Reported by Zixu Wu <zx at bv3.dev>
Approved by: Chris Hutchinson <portmaster at bsdforge.com> (maintainer)
Approved by: osa, vvd (Mentors, implicit)
Co-authored-by: Frank Wall <freebsd at moov.de>
Co-authored-by: Zixu Wu <zx at bv3.dev>
Security: GHSA-5538-7cxj-5jcc
MFH: 2026Q3
(cherry picked from commit 87d11fd7305cb245dff284e34be3a5c0c423aa60)
net/turnserver: Update 4.14.0 => 4.16.0
Port changes:
- Run turnserver as non-root by default.
- Pet port(lint|fmt|clippy).
PR: 297251, 296810
Reported by: Frank Wall <freebsd at moov.de>
Reported by Zixu Wu <zx at bv3.dev>
Approved by: Chris Hutchinson <portmaster at bsdforge.com> (maintainer)
Approved by: osa, vvd (Mentors, implicit)
Co-authored-by: Frank Wall <freebsd at moov.de>
Co-authored-by: Zixu Wu <zx at bv3.dev>
Security: GHSA-5538-7cxj-5jcc
MFH: 2026Q3
Firewall: Rules: Add max-pkt-rate (Rate limiting) (#10629)
* Firewall: Filter: Add max-pkt-rate
* Move dialog options, they dont fit with the stateful firewall options
* Give it an own Rate limiting header, it doesnt semantically fit anywhere else
Stop one thing we do not own from costing every app
## Problem
`create_app` runs inside the `app.create` job for its own name, so the query it asks to find out whether that name is free hides an app with no metadata and no containers as an install in flight - which is exactly what a directory an earlier install abandoned before writing any metadata looks like. The new install then merged itself into the stale tree.
Docker reports every compose project on the box, including ones the user deployed themselves, and we took the `ix-` prefix off the name without checking it was there. A project called `webserver` read as an app called `server`: reported as broken and offered for deletion against a name that is not ours, filtering a genuinely installed app of that name out of the scan behind it, and lending it containers it does not own. A project called exactly `ix-` read as an app with no name at all, which the API model refuses - and that took `app.query` down for every app on the box.
An entry of the collective config file is whatever yaml parsed it as, and a value which is not a mapping flowed into an entry the API model describes as one, so a healthy running app was reported in the `ERROR` state and lost every operation but deletion.
A row we cannot even name - which only a `select` that took away both `name` and `id` produces - was let out of the conversion, and one of those returned nothing at all for every app installed.
## Solution
- **Whatever is on disk, the name is taken until it is deleted.** The directory is tested directly, since it is the one thing the in-flight suppression cannot hide.
- **A compose project which does not carry our prefix is not an app.** Guarded in the loop rather than in the name helper, whose other two callers want the slice as it stands - one of them is `app.stats`, which would start failing outright for anyone running a stack of their own.
- **A collective config entry which is not a mapping is passed over** in favour of the app's own file, which is parsed as one or not read at all.
- **A row we cannot name is left out of the list** instead of failing it. `get: true` still raises, since there is one entry it has to hand back or explain.
The last of these is the backstop for the second: an unnamed project is the only source of an unnameable row we know of today, and neither change makes the other redundant.
[Docs][AMDGPU] fully specify volatile accesses in the memory model
A volatile access on AMDGPU includes store-available or load-visible semantics
at the widest scope supported by its address space:
- system scope for global/generic,
- workgroup scope for local (LDS)
This fully specifies the behavior that the LLVM memory model leaves
target-dependent, matching the implementation in SIMemoryLegalizer.
Assisted-By: Claude Opus 4.8
Store USB passthrough identity as a physical port
## Problem
`vm_device.attributes['device']` and `container_device.attributes['device']` held a single overloaded string. Through 25.10 it was a libvirt nodedev name, which encodes a sysfs port path; in the 26.0 pre-releases it became a bus/devnum pair, and a devnum is reassigned on every replug and reboot. Nothing in the row recorded which meaning it carried, so an upgraded row resolved to whatever device currently held that number — silently, with no error. Separately, `_extract_identity` probed udev live, once per existing device, on every device validation.
## Solution
- Replaced `device` with `port` on the VM and container USB models, mutually exclusive with `usb`, and tightened the vendor/product pattern from `^0x.*` to four hex digits. A version adapter maps `device` onto `port` for pre-26 clients, which is exact rather than a guess: every value such a client can send is a port path by definition.
- Added an alembic migration that rewrites stored rows through a pure string transform. It never probes hardware, so it stays correct when `config.upload` replays it against a database from another machine.
- `container_device` only ever existed in 26.0, so every `device` value in it is a devnum, and a devnum cannot be turned into a port without live hardware. Those rows are dropped with a log line naming the container rather than silently pointing at a plausible but wrong socket. Rows the API could not read back — no identity at all, or a malformed vendor/product id — are dropped the same way: one such row degrades the entire `vm.device.query` reply, and fails the call outright for clients on a legacy API version.
- `_extract_identity` no longer touches hardware. Port and vendor/product are now separate identity domains, which also removes the N+1 udev scan from the uniqueness check.
- The Incus migration resolves busnum/devnum to a stable port while the device is still attached, which is the only point at which that is possible, and skips what it cannot resolve instead of writing a row that will never resolve again. It also stops prefixing `0x` onto ids that already carry one, which used to produce `0x0xabcd` and pass the old loose pattern.
pseudofs: Don't purge the cache on shutdown
This is a waste of time and results in a use-after-free if linsysfs is
loaded and a USB network interface is in use, since USB devices are
disconnected at shutdown, which triggers a call into linsysfs, which
then tries to destroy a pseudofs node which has already been purged.
MFC after: 1 week
Reviewed by: glebius
Differential Revision: https://reviews.freebsd.org/D58359
Keep container records unless their pool was really destroyed
## Problem
The container FS attachment delegate was the only stateful-workload delegate whose `delete()` destroyed configuration: it undefined the libvirt domain and removed the `container_container` and `container_device` rows, while deliberately leaving the rootfs dataset alone. VMs and apps only stop. That made `pool.export(cascade=True, destroy=False)` — the flow that exists precisely because the pool is moving elsewhere intact — permanently orphan live storage. A container's definition, devices and idmap slice live only in SQLite, nothing on disk can rebuild them (unlike the migrated incus containers, we write no manifest), and a freed idmap slice can be reissued to another container while the surviving rootfs still carries its UID range.
`pool.dataset.delete` reached the same code with no cascade flag at all, so deleting a dataset that a container merely bind-mounted as a FILESYSTEM device destroyed the whole container. And since `query()` only reports containers in ACTIVE_STATES, the cleanup was not even coherent — it dropped the records of running containers and kept those of stopped ones.
## Solution
- **`delete()` is now stop-only**, matching the VM and apps delegates. Records are never removed from the delegate. The unconditional `etc.generate` that hung off its `for`/`else` goes with them — there was no `break` for that `else` to guard.
- **Record removal moved to a new `destroy()` step on the attachment delegate**, which `pool.export` calls once the zpool destroy has returned — the only point that can see whether the data actually went away. `delete()` still has to run first so the datasets are released, whereas discarding configuration is safe only once the data it describes is confirmed gone, and everything in between (the `pool.pre_export` hook, `kill_processes`, the destroy itself) can abort the job with the pool still fully intact. It is gated on `cascade` together with a `destroyed` flag reflecting what the export really did rather than `options['destroy']`: asking to destroy an OFFLINE pool leaves it untouched on its disks, so the requested option on its own would still have discarded records whose storage was intact. The base implementation is a no-op, since the share/task delegates already disposed of their attachments in `delete()` while the pool was still there; the container one matches on the pool its root dataset lives on and ignores runtime state, so stopped containers are cleaned up too, and a container merely bind-mounting the destroyed pool keeps its definition.
- **Containers are re-pointed at their storage when a pool is imported under a new name.** The dataset is always `<pool>/.truenas_containers/containers/<name>`, so the new location is derived rather than guessed. The remap is committed only when the old pool is genuinely gone, the derived dataset exists, and no other container claims it; each container is applied behind its own boundary so one failure cannot abort the import or block the rest.
- **`pool.reimport` no longer starts everything on the pool.** It walks the delegates in start-priority order (it was using registration order, quietly defeating the docker/apps ordering) and calls a new `start_on_import`, which containers and VMs override to honour `autostart`. Previously every stopped container and VM on the pool came up regardless.
Also documents why `storage_paths()` derives the container root from the dataset name rather than its real mountpoint — both consumers need the name-derived form, and switching to the mountpoint would silently stop matching containers on pool export and lock.
[flang] Add an example plugin exercising the HLFIR pipeline extension points
The HLFIR extension points, the config augmentor registry and fir-opt's symbol
export exist to let an out-of-tree MLIR pass run while the HLFIR intrinsic
operations (hlfir.sum, hlfir.matmul, ...) are still present. None of that was
covered end to end, and there was no worked example of how to use it.
Add flang/examples/HLFIRPipelinePlugin, modelled on PrintFlangFunctionNames. It
contributes a pass that prints the HLFIR operations still present in the
module, tagged with the pipeline position it was inserted at, and exposes it
through both plugin entry points: a static initializer calling
fir::registerPassPipelineConfigCallback for the `flang -fc1 -load` path, and
mlirGetPassPluginInfo so fir-opt can load it with --load-pass-plugin.
Nothing is linked into the shared object: MLIR, FIR and flang symbols resolve
against the host tool, which is what export_executable_symbols_for_plugins on
flang and fir-opt provides. Removing the fir-opt export drops it from ~105k
exported dynamic symbols to one and makes --load-pass-plugin fail to load.
[7 lines not shown]
[flang] Add a pass-pipeline config callback hook for plugins
The HLFIR-to-FIR pipeline extension points live on MLIRToLLVMPassPipelineConfig,
which the frontend builds as a local of CodeGenAction, out of reach of a plugin.
Add a process-global registry of callbacks that run on the config before the
pipeline is built. A plugin registers one from a static initializer, so it is in
place before any compilation begins, as FrontendPluginRegistry does for plugin
actions. Both code generation entry points invoke the callbacks, lowerHLFIRToFIR
for -emit-fir and generateLLVMIR for -emit-llvm/-emit-obj, and are mutually
exclusive for a given compilation, so a plugin sees the same behaviour whichever
output was asked for.
Co-Authored-By: Claude Opus 5 <noreply at anthropic.com>
Remove documentation of OBJ_add_object(3)
This API was removed a long time ago but I forgot to update the manpage
(probably because doing so is slightly non-trivial).
There's still a lot of API here that should be removed. OBJ_add_objects()
seems now unused while OBJ_new_nid() is used by the one consumer that is
single-handedly responsible for at least two dozen APIs that could otherwise
be removed from libcrypto with significant simplifications: security/xca.
It would appear the author is on a quest to figure out how to make use of
whatever undocumented garbage they can find in the openssl headers. That's
of course a hobby project you can pursue for decades.
syslogd: Preserve full partial klog line when buffering
Buffer incomplete /dev/klog lines from the start of the original
line instead of the parse position. Otherwise, split messages
lose the BSD syslog priority prefix when reconstructed.
Fixed by Kenichi Suzuki at IIJ.
[LV] Make greater use of ScalarEvolution in addDiffRuntimeChecks (#213668)
When the loop vectoriser calls addDiffRuntimeChecks it goes to a lot of
effort to avoid generating multiple copies of the VF calculation by
caching the first instance. However, now that ScalarEvolution has a
getElementCount function we can simplify this code significantly,
especially since SCEVs are also implicitly cached. Make greater use of
SCEVs for computation also has the side-effect of improving code quality
in the memory check blocks, which is important when estimating costs of
these checks. You can see this in some tests like
LoopVectorize/AArch64/sve-runtime-check-size-based-threshold.ll
where the threshold for entering the loop has been relaxed.
Ideally, all computation in addDiffRuntimeChecks should be done using
SCEV because there are presumably other folds that can be applied to the
comparisons. However, I'd keep things simple in this PR and deal with
that in a follow-on PR.
lang/ldc: add new bootstrap for powerpc64le after long double switch
Two new patches:
1. Don't use glibc's dual long double mechanism - we don't support
IBM long double.
2. Use proper mangling.
