[lldb] Keep DWARF dereference results address-sized (#216666)
`DW_OP_deref` and `DW_OP_deref_size` produce the DWARF generic type, but
the
ordinary memory paths left the `uint64_t` returned by `GetMaxU64` on the
expression stack. This made their results 64 bits even when evaluating
an
expression for a 32-bit target.
Normalize successful memory dereference results to the target address
width
using unsigned extension. Add i386 unit coverage for both operations,
including the `DW_OP_deref_size` zero-extension behavior and explicit
APSInt
width checks.
Fixes #210991.
AMDGPU: Fix broken undef operand handling in SIFixSGPRCopies (#217385)
This would hit a null dereference on a failed getVRegDef call,
and then fail to propgate the undef flag.
Co-Authored-By: Claude claude-opus-4.8 <noreply at anthropic.com>
[SLSR] Add a statistic counting candidate-basis SCEV differences (NFC) (#217143)
In worst-case O(n^2) traversal scenarios, `getMinusSCEV()` can cause
long compile times.
Add a statistic to track `getMinusSCEV()` calls to help debug these
scenarios.
[libc++][test] Remove `XFAIL` mark for LLVM libc on `system` (#217237)
Recently, LLVM libc has `system` implemented in
8c28e298827d1777009f4599ae161abef9491f34, so the tests for `<cstdlib>`
and `<stdlib.h>` pass now.
[flang][Driver] Forward negative sum reassociation flag (#217266)
Previously, only a flag which alters the default was forwarded to the
frontend driver. This works upstream, but it meant that the negation
flag was not forwarded (as negation is the default) which then breaks as
soon as the default is changed. This led to some confusion when I tested
a downstream branch with the flag enabled by default.
Instead, forward the last explicit sum reassociation option to the
frontend driver so the negative spelling is not lost by the driver.
Assisted-by: Codex
cad/openvsp: Update to 3.51.3
ChangeLog: https://openvsp.org/blogs/announcements/2026/08/17/openvsp-3-51-3-released
Features:
* API code examples now serve as unit tests
* AI Audit for API completeness
* VSPAERO Outputs more stuff for dynamic analysis
Build System:
* Update AngelScript to v2.38
* Improve Python MANIFEST.in and packaging
Bugs:
* Fix AngelScript registration of vec3d and Matrix4d
* Fix thin shell inertia calculation
[4 lines not shown]
[flang][OpenACC] Avoid allocation actions for unified memory. (#217146)
Under `-gpu unified`, the dynamic allocations are accessible
on host and device, so there is no need generate pre/post-alloc/dealloc
actions for `acc declare` variables' allocations.
[lldb] Pass --enable-mte from lldb-dotest (#217176)
lldb-dotest prepends darwin-mte-launcher, which runs the test suite and
the debuggees it spawns, which inherit MTE, with memory tagging enabled.
It never passed --enable-mte to dotest, so configuration.mte_enabled
stayed False and the MTE-aware decorators (like @skipIfMTE) were
silently inert.
The lit configuration already derives the flag from LLDB_ENABLE_MTE in
lit.cfg.py; do the same in lldb-dotest so the two runners agree.
Assisted-by: Claude
[lldb] Interpret the DW_OP_plus_uconst addend in the popped operand's… (#217239)
… typeFor typed DWARF values, `DW_OP_plus_uconst` must add the ULEB128
addend
in the same explicit base type as the popped operand (DWARF v5,
2.5.1.4).
LLDB forwarded the operation to `uint64_t` `Scalar` arithmetic: the
addend was implicitly converted to a 64-bit unsigned `Scalar`, and
`Scalar::operator+=` then promoted the narrow operand to 64 bits before
adding. This destroys the wraparound semantics of the original base
type, e.g. `(unsigned char)0xff + 1` evaluated to `0x100` instead of 0.
Construct the addend with the popped operand's exact integer type (bit
width and signedness) so the addition is performed in that type and
wraps accordingly. Non-integer operands keep the existing promotion
behavior.
Adds a `DW_OP_plus_uconst_typed` unit test covering unsigned and signed
[2 lines not shown]
Resolve migrated USB devices by their vendor and product ids
## Problem
A USB passthrough device is named after the port it is plugged into, which is what 25.10 stored. The 26.0 pre-releases built the same shape of name out of the bus and device number instead, and migration 0021 was added to convert those. It cannot do that job: nothing on either device table records which build wrote a row, so it has no way to tell a device-number value from a correct one and rewrites both. A container row written by any current build, or a 25.10 VM row whose device happened to be unplugged at the upgrade boot, is silently repointed at whatever now holds those digits. No shipped release ever wrote a device-number name, so everything the migration could fix is pre-release while everything it can break is not.
The incus migration had the same preference the same way round: it resolved a device by the bus and device number the manifest carried and fell back to the vendor and product ids only when those were missing, choosing the counter the kernel reissues over the identity that survives a replug. It runs once per machine and is never run again, so a wrong row it writes stays wrong.
## Solution
- **Migration 0021 is removed.** Without it every upgrade path is already correct, because the names 25.10 stored are the names the current code produces.
- **Only the vendor and product ids identify a device.** The bus and device number takes no part in resolution. A manifest device that does not carry both ids is dropped rather than guessed at, and the reason is logged: this migration cannot be repeated, and a row built from a stale address is a wrong row that nobody afterwards can tell is wrong.
- **Ids that no connected device carries are still stored as ids.** The device is merely unplugged, and a row saying what the user asked for stays visible and editable rather than disappearing.
- **One device per row.** Rows written for a container claim what they point at, so two manifest devices can no longer land on one port or one pair of ids, which used to leave a container that could neither start nor be edited back. Where several identical devices are connected, each row takes the first one still free.
- **A device that cannot be resolved at start reads as an error rather than a traceback.** pylibvirt's own exception type is caught at both start call sites and reported as a `CallError`, which is what 25.10 did.
- Every resolution is logged, not only the failures. Nothing on the row records which identity it came from, the job log does not survive a restart, and the migration never runs again, so this is the only thing that makes a wrong outcome reconstructable later.
Devices whose manifest carries no usable vendor and product ids are now dropped where they previously became a row built from the recorded bus and device number. That is deliberate and it is permanent: there is no second run and no repair path. In practice the affected set is small, since anything selected through the 25.10 UI carried all four fields.
Interfaces: Assignments - add interface configuration settings in new assignments page. for https://github.com/opnsense/core/issues/10568
Refactor NetworkInterface model to reuse existing property names as much as possible, move from/to legacy logic into a custom fieldtype and store all legacy settings in a container named "pending" to ease reconfiguration and updating legacy configurations.
Skip wireless and other advanced settings for now, only implement a minimal set of validations.
ExpandIRInsts: Expand frem when the libcall is unavailable (#217301)
The legalizer actions have a distinct LibCall kind, separate
from Expand. If the target specifies LibCall, but the call is not
available, fall back to expand. The action is a fixed property
of the subtarget, but the library call availability in the future
will be program state that depends on module flags.
The test is underhanded and exploits a defect in llc's -march
flag handling. Since the library call set is computed from the Module's
triple, and the module has no triple, the computed libcall set is
empty for the apparently unknown arch. Any real triple will have
an frem call, so the only observable case is this buggy -march case.
In the future module flags will be able to remove the call from
the usable set.
Co-authored-by: Claude (Claude-Opus-4.8)
gettext-tools: do not autodetect libcurl and libjson-c
Fixes build on OpenIndiana. The libraries are shipped
with base but at least some of the headers seem absent.
Resolve migrated USB devices by their vendor and product ids
## Problem
A USB passthrough device is named after the port it is plugged into, which is what 25.10 stored. The 26.0 pre-releases built the same shape of name out of the bus and device number instead, and migration 0021 was added to convert those. It cannot do that job: nothing on either device table records which build wrote a row, so it has no way to tell a device-number value from a correct one and rewrites both. A container row written by any current build, or a 25.10 VM row whose device happened to be unplugged at the upgrade boot, is silently repointed at whatever now holds those digits. No shipped release ever wrote a device-number name, so everything the migration could fix is pre-release while everything it can break is not.
The incus migration had the same preference the same way round: it resolved a device by the bus and device number the manifest carried and fell back to the vendor and product ids only when those were missing, choosing the counter the kernel reissues over the identity that survives a replug. It runs once per machine and is never run again, so a wrong row it writes stays wrong.
## Solution
- **Migration 0021 is removed.** Without it every upgrade path is already correct, because the names 25.10 stored are the names the current code produces.
- **Only the vendor and product ids identify a device.** The bus and device number takes no part in resolution. A manifest device that does not carry both ids is dropped rather than guessed at, and the reason is logged: this migration cannot be repeated, and a row built from a stale address is a wrong row that nobody afterwards can tell is wrong.
- **Ids that no connected device carries are still stored as ids.** The device is merely unplugged, and a row saying what the user asked for stays visible and editable rather than disappearing.
- **One device per row.** Rows written for a container claim what they point at, so two manifest devices can no longer land on one port or one pair of ids, which used to leave a container that could neither start nor be edited back. Where several identical devices are connected, each row takes the first one still free.
- **A device that cannot be resolved at start reads as an error rather than a traceback.** pylibvirt's own exception type is caught at both start call sites and reported as a `CallError`, which is what 25.10 did.
- Every resolution is logged, not only the failures. Nothing on the row records which identity it came from, the job log does not survive a restart, and the migration never runs again, so this is the only thing that makes a wrong outcome reconstructable later.
Devices whose manifest carries no usable vendor and product ids are now dropped where they previously became a row built from the recorded bus and device number. That is deliberate and it is permanent: there is no second run and no repair path. In practice the affected set is small, since anything selected through the 25.10 UI carried all four fields.
[flang][OpenACC] Rematerialize fir.absent in outlined regions. (#217103)
`OffloadTargetVerifier` complains about `!fir.boxchar<>` live-in
produced by `fir.absent`. It should be always legal and profitable
to rematerialize `fir.absent` inside the outlined regions.
ibus: regenerate tools Vala sources before build
The generated tools/main.c in the distfile may contain Wayland code
even when ibus is configured with --disable-wayland, causing the build
to fail due to missing wayland headers or libraries.
Clean the generated sources before build so they are regenerated
with the current configure options, as already done for ui/gtk3.
This should fix workaround for PR pkg/60476 on pkgsrc-2026Q2.
[AMDGPU] Add missing IsFlat check in misaligned tuple spill handling (#217353)
The misaligned tuple handling added in #183701 rewrites the spill opcode
via getFlatScratchSpillOpcode without checking IsFlat. This causes a
MUBUF spill of misaligned tuples to be rewritten into an invalid flat scratch
opcode carrying MUBUF operands.
To reproduce on main:
llc -mtriple=amdgpu9.0a-amd-amdhsa -verify-machineinstrs \
-run-pass=prolog-epilog llvm/test/CodeGen/AMDGPU/vgpr-spill.mir -o -
Only gfx90a is affected. Add it to vgpr-spill.mir's run lines.
Bug was discovered while working on Issue #129199.
