[SimplifyCFG] Bail out on trivial cases in `mergeNestedCondBranch` (#212309)
Closes https://github.com/llvm/llvm-project/issues/212300.
When BB3 is identical to BB4, it is no longer profitable to perform this
fold, since it creates an unused xor instruction. The DomTree update
issue is also easy to fix. But I think this solution is better.
The following IR was dumped just before this function:
```
define void @func(i1 %cond1, i1 %cond2, i1 %cond3) {
entry:
br i1 %cond1, label %bb2, label %else
else: ; preds = %entry
br i1 %cond2, label %bb0, label %common.ret
bb0: ; preds = %else
br i1 %cond1, label %bb1, label %bb2
[12 lines not shown]
NAS-141984 / 26.0.0-RC.1 / Fix small bugs in NFS code (#19418)
`sanitize_networks` and `sanitize_hosts` reported incorrect error
messages when wildcard host/network was not the last on the list.
`clear_nfs3_rmtab` accepted mutable value as default argument. This
didn't affect anything currently, but can potentially result in memory
leaks and weird behavior if code is modified.
`dbgflg` was a leaked loop variable that worked by accident
Backported from https://github.com/truenas/middleware/pull/19417
[mlir]Add resultSegmentSizes/operandSegmentSizes to prop-dict. (#211222)
`setPropertiesFromParsedAttr` (generated by `OpFormatGen.cpp` for ops
using a custom `assemblyFormat`) rejects the trait-injected
`operandSegmentSizes` /. `resultSegmentSizes` properties when they
appear in a `prop-dict`, even though the printer emits them there for ops
whose format uses a bulk operand/result type directive
(`type(operands)`, `type(results)`, `functional-type(operands, results)`).
This breaks round-tripping: any op combining `AttrSizedOperandSegments`
/ `AttrSizedResultSegments` with such a bulk directive fails to re-parse
its own printed output, because printer-side elision of these keys
(introduced in #115930) is intentionally skipped in that case — the
sizes can't be reconstructed from individually-typed operand/result
groups, so they must survive in the text, but the custom parser was never
taught to read them back.
`setPropertiesFromAttr` (used by the generic-form parser, bytecode, and
C++ construction) already special-cases these two keys, so this change
[12 lines not shown]
AMDGPU: Remove dead FEATURE_FP64/FEATURE_LDEXP from ArchFeatureKind (#212479)
No GPU ever sets these bits, and clang's hasFP64()/hasLDEXPF()
short-circuit on isAMDGCN() before testing them, so the bits are
never observed.
Co-authored-by: Claude (Claude-Opus-4.8)
Revert "Add a few missed files to ObsoleteFiles.inc"
This reverts commit 33175a5059970bf9e888a799d3578e2902d765af, because
some of the directories and files are still being installed.
Revert "Add a few missed files to ObsoleteFiles.inc"
This reverts commit 2e089a89812b56329741cd8dc2d272405a6e73ff, because
some of the directories and files are still being installed.
[LLVM][CodeGen] Clean up uses of useSVEForFixedLengthVectorVT(). (#211605)
During lowering `useSVEForFixedLengthVectorVT` only serves to separate
NEON sized vectors from those made legal for SVE VLS. When no separation
is required there is no reason to call the function. That means
`useSVEForFixedLengthVectorVT(VT, /*OverrideNEON=*/true)` is largely
synonymous to `isSVEorStreamingSVEAvailable()`.
`useSVEForFixedLengthVectorVT` is not a per operation property. For this
reason I have removed the AllowBF16 parameter and replaced it by a
command line option that can be used during SVE VLS bfloat bringup. The
one existing use has been removed because it falls under the previous
issue in there being no need to call `useSVEForFixedLengthVectorVT`.
[X86] Reapply #210739 with a fix (#212020)
This reapplies #210739, which was reverted in #211958 because it could
crash the backend with "Invalid rip-relative address" when an LEA added
a RIP-relative global and an already-materialized value.
Fixes #51707
Migrate legacy containers on HA systems
## Problem
The `system.ready` handler that triggers the incus->container migration returns early on failover-licensed systems, since the failover event plugin owns starting containers there. That path only starts them, it never migrates, so legacy incus containers on an HA pair are never brought across - and `.ix-virt` is no longer hidden or delete-guarded, so they are one dataset deletion away from being destroyed.
## Solution
Move the migrate-then-start ordering into a shared private method and call it from both the `system.ready` path and the failover path, so the two cannot drift apart again.
Leave the legacy datasets as the migration found them
## Problem
Two loose ends in the migration's clean-up. Migrating a pool gives `<pool>/.ix-virt` and `<pool>/.ix-virt/containers` an inherited mountpoint so their children can be mounted and never puts it back, permanently promoting the legacy tree into `/mnt/<pool>/.ix-virt` even on a run where nothing was migrated - incus had both at `mountpoint=legacy`, i.e. never mounted. And when a skipped container's own mount properties cannot be restored, that is reported only in the middleware log, while every other per-container outcome goes to the job log the user actually reads.
## Solution
Restore `mountpoint=legacy` on both parents once a pool has been processed, children first so the parent is not unmounted out from under one of them; a failure there is logged and does not fail the migration. Pass the job into the per-container revert so its two failure paths are reported in the job log as well.
Arm the mount-property revert before the properties are changed
## Problem
The migration mounts each legacy container to read its manifest, which means replacing the `canmount`/`mountpoint` pair incus set, and a `finally` restores them for any container that is not migrated. The flag guarding that restore was only set once the mount had succeeded, so a failure part-way through the property update - `canmount` applied, `mountpoint` not - left the dataset changed with nothing left to change it back.
## Solution
Set the flag before the properties are touched rather than after the mount.
Record containers created during the migration
## Problem
The set of existing container names is built once before the storage pools are walked, so a container the migration itself creates is never added to it. Two legacy containers with the same name in different pools therefore both proceed, and the second one fails validation after its dataset has already been renamed.
## Solution
Add each container to the set as it is created, so a later pool skips the name instead of failing on it.
Relocate migrated container origins out of legacy .ix-virt
## Problem
Incus containers are ZFS clones of an image snapshot. The incus->container auto-migration relocated each container from `<pool>/.ix-virt/containers/<name>` to `<pool>/.truenas_containers/containers/<name>` with a bare `zfs rename` and did nothing else. A `zfs rename` does not change a clone's `origin`, so a migrated container stayed a clone of a snapshot still living inside `.ix-virt`. `.ix-virt` was visible in the UI and not delete-guarded, so deleting it recursively destroyed those origin snapshots and cascaded into the dependent migrated clones — silently destroying migrated containers.
## Solution
Relocate each container's origin image dataset out of `.ix-virt` before renaming the container, so no migrated container depends on anything under `.ix-virt`. Once relocated the image stays put for good, exactly like a natively pulled one — reclaiming either is the job of the `container.image.*` management API landing separately in this release, not of this fix.
- **Shared relocation helper** — `container.relocate_container_origin` reads a container's live `origin`; if it points at an image under `.ix-virt/images` or `.ix-virt/deleted/images`, it sets `canmount=noauto` on that image dataset and then renames it into the native `.truenas_containers/images/` tree. The rename goes last so it is the single atomic commit point: the image is either wholly still in `.ix-virt` or wholly relocated, never half-way, and the helper's return value describes reality. All fan-out clones auto-repoint on the rename; an origin already outside `.ix-virt` is left alone; a relocation failure leaves the container wholly inside `.ix-virt` (best-effort, skip).
- **Migration path** — the incus->container migration calls the helper immediately before renaming each container, and skips any container whose base image cannot be relocated.
- **Repair migration** — new `0020_repair_incus_clone_origins` runs the same relocation over existing `container.container` rows for systems that already ran the old migration.
- **Delete guard** — `.truenas_containers` is added to `INTERNAL_PATHS` so it cannot be deleted out from under running containers; the plugin's own snapshot/clone/destroy calls that touch it now pass `bypass=True`.
- **Safer deletion** — `do_delete` destroys the dataset first (recursively, matching the apps stack, so a container that has snapshots is deletable) and removes the database and libvirt records only once the dataset is confirmed gone, so a failed destroy never orphans the dataset with no row pointing at it; an already-missing dataset is tolerated so a container whose data was lost to the old cascade can still be removed cleanly.
- **Active-instance guards** — deleting or renaming a container that is not stopped (running or suspended) is refused; delete additionally accepts `force=True`, which stops it first, mirroring the VM delete flow. The container status model now includes the `SUSPENDED` state it can actually report.
- **Delete locking** — delete becomes a job so it can stop the container and wait on the destroy, and its lock is keyed per container id: a constant lock string would hit `@job`'s default `lock_queue_size` of 5 and, past five queued deletes, silently fold a new request into a queued delete of a *different* container and hand that job back to the caller, who would then see SUCCESS for a container nobody deleted.
