[libc++][pstl] Implementation of parallel std::lexicographical_compare() based on std::mismatch() (#212366)
This PR adds an implementation of parallel
`std::lexicographical_compare()` based on parallel `std::mismatch()`.
The implementation is close to a one-liner:
```c++
auto __res = _Mismatch()(__policy, __first1, __last1, __first2, __last2, [&](_Ref1 __lhs, _Ref2 __rhs) {
return !__comp(__lhs, __rhs) && !__comp(__rhs, __lhs);
});
```
Included tests check that:
- Semantics of the iterator-only version is correct.
- Semantics of the predicated version is correct.
- The functions correctly SFINAE out when the first argument is not an
execution policy.
- The `noexcept` policy is followed.
- The `nodiscard` policy is followed.
[2 lines not shown]
[SPIRV] Legalize Cast Instructions for Matrix Types (#212619)
fixes #186864
This is a more limited fix. that doesn't require us to change the whole
legalization strategy for SPIR-V.
To get the last fix to work it looks like I would have to have changed
every global opcode to no longer use power of 2 based legalization.
This change with power of 2 fixed the transpose case in the offload
testsuite when we do the conversion of bools to i32s before we call
transpose.
There remains an issue when a i1 makes it into a transpose intrinsic.
That said I can only trigger that case via llvmir and not HLSL so will
move on for now.
[lldb] Ask the reporter what happened in a bug report (#213173)
A diagnostics bundle records the state of the debugger, never what the
user was doing or what they expected instead, so reports arrive with a
generic title and no description of the problem. Pre-fill the report
with the questions only the person filing it can answer, and print a
checklist when the bundle is written so an incomplete report doesn't get
shared as-is.
rdar://183356348
Reapply "[NFC][clang][Driver] Add tests for --driver-mode=flang" (#211724)
This reapplies #207658.
Some targets do not support flang_rt or clang_rt.
It seems difficult to create a blocklist, so the tests are now
configured to explicitly specify the known-working targets.
The specified targets are extracted from tests in flang/test/Driver.
-----
The original commit message:
This patch intends to clarify the current behaviors, not to state the
expected/desirable behaviors.
e1000: fix 82574 MSI-X interrupt throttling
em_newitr() and the per-queue interrupt_rate sysctl both tested
que->msix to decide whether an 82574 is running in MSI-X mode. 0 is a
valid MSI-X vector so queue 0 was misclassified as legacy/MSI.
Test sc->intr_type == IFLIB_INTR_MSIX instead. While here, index the tx
EITR read by tque->msix rather than tque->me so it matches the register
em_newitr() actually writes; the two differ once tx_num_queues exceeds
rx_num_queues.
Also seed que->itr_setting in em_initialize_receive_unit() with the rate
the hardware was just programmed with. Otherwise an itr_setting left
over from AIM across an interface re-init makes the change detection in
em_newitr() suppress the write that would restore it, leaving the
hardware at the default rate while software believes otherwise.
Fixes: 3e501ef89667 ("e1000: Re-add AIM")
(cherry picked from commit 941113a0097ea047bd493f7f78b384718249779d)
e1000: fix 82574 MSI-X interrupt throttling
em_newitr() and the per-queue interrupt_rate sysctl both tested
que->msix to decide whether an 82574 is running in MSI-X mode. 0 is a
valid MSI-X vector so queue 0 was misclassified as legacy/MSI.
Test sc->intr_type == IFLIB_INTR_MSIX instead. While here, index the tx
EITR read by tque->msix rather than tque->me so it matches the register
em_newitr() actually writes; the two differ once tx_num_queues exceeds
rx_num_queues.
Also seed que->itr_setting in em_initialize_receive_unit() with the rate
the hardware was just programmed with. Otherwise an itr_setting left
over from AIM across an interface re-init makes the change detection in
em_newitr() suppress the write that would restore it, leaving the
hardware at the default rate while software believes otherwise.
Fixes: 3e501ef89667 ("e1000: Re-add AIM")
(cherry picked from commit 941113a0097ea047bd493f7f78b384718249779d)
Merge tag 'v7.2-rc5-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6
Pull smb client fixes from Steve French:
- fix SMB1 read and write potential buffer leaks
- netfs error handling fix
- fix check for last write time in truncate and setattr and cleanup use
of smb_store_release()
- fscache fix and cleanup
- validate idmap key payload length
- minor SMB1 error mapping cleanup
- witness protocol memory allocation fix
[10 lines not shown]
Merge tag 'for-v7.2-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply
Pull power supply fixes from Sebastian Reichel:
- Documentation build fix for bd71828
- max17040: handle missing status supplier
- macsmc: Support macOS 27 SMC firmware
- bq25890: fix the -10 C NTC lookup entry
* tag 'for-v7.2-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply:
power: supply: bq25890: fix the -10 C NTC lookup entry
power: supply: macsmc: Support macOS 27 SMC firmware
power: supply: max17040: handle missing status supplier
power: supply: bd71828: add a terminating table border
[CIR] Pointer and vptr width from a CIR-native data-layout entry (#204185)
PointerType and VPtrType have hard-coded sizes and alignments of 64/8
bits. On targets with 32-bit pointers (e.g., nvptx, spirv32), this trips
the record layout builder. Any record containing a pointer hit the
insertPadding assertion (offset >= size)
because the pointer was sized at 8 bytes while the following field was
placed at the AST-mandated 4-byte offset.
### Changes:
- CIRGenerator: attaches a CIR-native cir.ptr data-layout entry at
module setup, storing {size-in-bits, abi-align-in-bits} read
from the target DataLayout (only for the default address space).
- CIRTypes: PointerType reads its size/alignment from that entry
(falling back to 64/8 when absent); VPtrType routes through a cir.ptr so
it picks up the same width.
- LowerToLLVM: strips the cir.ptr entry during CIR→LLVM lowering, since
cir.ptr has no meaning in LLVM IR.
- Unit test: checking 4-byte pointer/vptr layout on nvptx, verified
across CIR, CIR→LLVM.
If the address of the isa_pointer is returned as an error don't ask if it is a tagged pointer (#213163)
The answer isn't right and the wrong type might stick and cause
downstream failures.
Note, the correct solution to this is to distinguish between "couldn't
get the address" and "got a real value of LLDB_INVALID_ADDRESS" but
piping an optional all the way down and then through all the uses is an
intrusive change which I don't have time for right now. That only risk
is that this really IS a tagged pointer with the value
LLDB_INVALID_ADDRESS, so this seems an acceptable workaround.
I ran across this when debugging the ObjC test failures in the ObjC
testuite after 8b9cce358bef26ae4cb9275dd6a43f903bafbaa0. This patch
clears up all those testsuite failures, which should stand as a test for
this patch when I resubmit that change.
[CIR] Implement most of 'musttail' statement attr (#213154)
This implements the basics, and leaves NYI in a few places (particularly
those that require cleanup calculations). There IS some additional work
that needs to be done when the ABI work is put in place as well, and the
thunk 'tail' hint isn't implemented either, and is left as a
missing-feature.
This is necessary for compiling the bytecode interpreter in Clang in a
few places during self-build.
[OpenMP][Offload] Fix use-after-free of the packed firstprivate transfer buffer (#212905)
`packAndTransfer()` called `submitData()`, which captured the address of
the data of
the `SmallVector` member of `PrivateArgumentManagerTy`, as the host
source of an
async transfer. The manager was later moved into an `AsyncInfo`
post-processing
lambda, changing the underlying address of the data:
`addPostProcessingFunction()`
copies the closure rather than moving it, but even if it "moved", the
address of the data owned by `SmallVector`'s inline capacity would have
changed.
The AMDGPU plugin read from the stale host source address when doing the
actual transfer.
Fix: allocate the packed buffer via
`getOrCreateSourceBufferForSubmitData()`, so
[2 lines not shown]
[lldb/docs] Document the remaining scripted-extension plugin categories (#213140)
`python_extensions.md` only covered the first five plugin categories.
This commit adds the missing sections for every plugin category added
since: `ScriptedBreakpointResolver`, `ScriptedHook`,
`ScriptedStackFrameRecognizer`, `ScriptedCommand`, `ParsedCommand`,
`ScriptedStringSummary`, and `ScriptedSyntheticChildren`.
Signed-off-by: Med Ismail Bennani <ismail at bennani.ma>
[lldb] Add target.jit-engine setting (#212998)
Add a target.jit-engine setting that lets users choose which LLVM
execution engine (MCJIT or ORC) is used to JIT expressions. Defaults to
MCJIT to preserve current behavior. This is groundwork for migrating
expression evaluation from MCJIT to ORC; IRExecutionUnit does not yet
consult this setting.
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` - and deleting `.ix-virt` recursively destroyed those origin snapshots and cascaded into the dependent migrated clones, silently destroying migrated containers. The migration also left the legacy parents mounted, moved on without a license, gave up on every remaining pool when one failed, and could leave a container renamed into the native tree with no database row pointing at it.
## Solution
Relocate each container's origin image out of `.ix-virt` before renaming the container, so no migrated container depends on anything under `.ix-virt`, and make the surrounding migration and deletion paths recoverable.
- **Shared relocation helper** - `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, and the return value describes reality. Fan-out clones auto-repoint on the rename; an origin outside `.ix-virt` is left alone; a container that is a clone of another container is refused, since the two would arrive entangled.
- **Migration path** - the migration calls the helper immediately before renaming each container and skips any container whose base image cannot be relocated, rather than producing one that looks healthy until `.ix-virt` is deleted.
- **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, and restores the legacy parents' mountpoint those runs left inherited.
- **Leave the legacy tree as found** - mount properties are reverted on any container that is not migrated, and the legacy parents are restored at the end of every run, so nothing is left mounted under `/mnt/<pool>/.ix-virt` with nothing managing it. Both reverts are armed before the properties are touched, since a partial apply has to be reverted too.
- **Migration robustness** - the migration is skipped on HA capable hardware and deferred (leaving the legacy configuration intact) when the system is not licensed for containers; one unusable pool no longer stops the pools after it; and a container whose dataset was renamed but whose row was never created is moved back where the user can see it.
- **Safer deletion** - the libvirt domain is torn down first so the container's runtime mounts are gone before ZFS is touched, the dataset is destroyed next, and the database records are removed only once it 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`, mirroring the VM delete flow, and is now a job locked per container id. The container status model gains the `SUSPENDED` state it has always been able to report.
Update to 1.07
Upstream changes:
1.07 - 2026-06-26
- Make _version work under mod_perl
1.06 - 2026-03-26
- Make tests pass for GnuPG 2.5.18
1.05 - 2025-08-12
- Make tests pass for GnuPG 2.4 versions (2.4.0 - 2.4.8)
audio/sox: Unbreak build when no audio devices are selected
Upstream allows this configuration so the port should as well.
PR: 297173
Approved by: Dan Nelson (maintainer)
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` - and deleting `.ix-virt` recursively destroyed those origin snapshots and cascaded into the dependent migrated clones, silently destroying migrated containers. The migration also left the legacy parents mounted, moved on without a license, gave up on every remaining pool when one failed, and could leave a container renamed into the native tree with no database row pointing at it.
## Solution
Relocate each container's origin image out of `.ix-virt` before renaming the container, so no migrated container depends on anything under `.ix-virt`, and make the surrounding migration and deletion paths recoverable.
- **Shared relocation helper** - `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, and the return value describes reality. Fan-out clones auto-repoint on the rename; an origin outside `.ix-virt` is left alone; a container that is a clone of another container is refused, since the two would arrive entangled.
- **Migration path** - the migration calls the helper immediately before renaming each container and skips any container whose base image cannot be relocated, rather than producing one that looks healthy until `.ix-virt` is deleted.
- **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, and restores the legacy parents' mountpoint those runs left inherited.
- **Leave the legacy tree as found** - mount properties are reverted on any container that is not migrated, and the legacy parents are restored at the end of every run, so nothing is left mounted under `/mnt/<pool>/.ix-virt` with nothing managing it. Both reverts are armed before the properties are touched, since a partial apply has to be reverted too.
- **Migration robustness** - the migration is skipped on HA capable hardware and deferred (leaving the legacy configuration intact) when the system is not licensed for containers; one unusable pool no longer stops the pools after it; and a container whose dataset was renamed but whose row was never created is moved back where the user can see it.
- **Safer deletion** - the libvirt domain is torn down first so the container's runtime mounts are gone before ZFS is touched, the dataset is destroyed next, and the database records are removed only once it 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`, mirroring the VM delete flow, and is now a job locked per container id. The container status model gains the `SUSPENDED` state it has always been able to report.
