Mk/Uses/npm.mk: Add support for pnpm >= 12
pnpm 12 has been rewritten in Rust and introduced an
architecture-dependent node module, which is required to be installed
separately from the main node module.
By default, the installation occurs upon the first pnpm execution and
breaks poudriere builds. So prefetch and extract the native executable
to the expected location in advance to avoid breakage.
Refactor subreg spilling logic.
Avoiding Lanebitemask manipulations.
Moved most of generic the calculations to use TargetRegisterInfo APIs.
Added a new API to get the covering subreg index given a lanebitmask.
[clang][bytecode] Reject matrix lvalue-to-rvalue casts in non-HLSL (#227305)
To fix test/CodeGen/AArch64/abi-classify-return-types.c.
The code path in the existing tests in
`test/SemaHLSL/Types/BuiltinMatrix/MatrixConstantExpr.hlsl` don't go
though `CheckLiteralType()`, so aren't rejected.
security/openssl: Security upgrade to 3.5.9
OpenSSL 3.0 is end-of-life and has known vulnerabilities.
Upgrade port to OpenSSL 3.5 by renaming security/openssl35
Security: 0d183075-bcb5-11f1-b09d-8447094a420
MFH: 2026Q3
[AMDGPU] Test precommit for subreg reload
This test currently fails due to insufficient
registers during allocation. Once the subreg
reload is implemented, it will begin to pass
as the partial reload help mitigate register
pressure.
[InlineSpiller][AMDGPU] Implement subreg reload during RA spill
Currently, when a virtual register is partially used, the
entire tuple is restored from the spilled location, even if
only a subset of its sub-registers is needed. This patch
introduces support for partial reloads by analyzing actual
register usage and restoring only the required sub-registers.
This improvement enhances register allocation efficiency,
particularly for cases involving tuple virtual registers.
For AMDGPU, this change brings considerable improvements
in workloads that involve matrix operations, large vectors,
and complex control flows.
lang/swift6: lang/swift6: Update to 6.4.0
Swift 6.4 has removed the ability for bootstrapping without a
pre-built host swift compiler. So now the port requires a bootstrap
swift toolchain regardless of the build mode.
The installation paths have been changed from
${PREFIX}/swift6/{bin,include,lib,...} to
${PREFIX}/swift6/usr/local/{bin,include,lib,...} to follow the
standard Swift toolchain layout.
Release Announcement: https://www.swift.org/blog/swift-6.4-released/
Reported by: GitHub (watch releases)
[MLIR][LLVMIR] Restore constant folding for global initializer GEPs
Before #226904, a GEP in a global initializer went through
IRBuilder::CreateGEP, and MLIR's IRBuilder<TargetFolder> folded the result
with ConstantFoldConstant. That combines nested GEPs, folds null and integer
bases, and infers inbounds and nuw when the offset stays within the global.
Building the constant expression directly skipped the folder, so the output
lost those flags.
Fold the constant again. This also applies to inrange GEPs, which used to
bypass the folder; the only visible difference there is that an inbounds
GEP with a non-negative offset now also gets nuw.
CIR's vtable, VTT and constant pointer tests check for the inferred flags
(for example CIR/CodeGen/vtt.cpp) and have failed since #226904.
Assisted-by: Claude Code (Claude Fable 5.1).
[MLIR][Remark] Make remark reporting thread-safe and order final remarks by source position
Passes nested under the multithreaded pass manager report into the same
RemarkEngine from worker threads, but nothing in the engine or the
policies was synchronized. RemarkEmittingPolicyFinal inserted into its
map from several threads at once, and under RemarkEmittingPolicyAll the
streamer, including the LLVM remark serializer, was called from several
threads at once. ThreadSanitizer reports both races in the new unit tests.
RemarkEngine now holds a lock around every call into the policy. It is a
recursive llvm::sys::SmartMutex, the same type as the DiagnosticEngine's
lock. report() takes it, and so does a new finalizePolicy(), which the
engine destructor and mlir-opt now use instead of calling finalize() on
the policy directly. For the All policy the streamer and the diagnostic
printer also run under the lock, so custom policies and streamers need no
lock of their own.
With the race fixed, the final policy's creation order is still not
deterministic: which thread reports first depends on scheduling.
[16 lines not shown]
dwc(4): Support a major update of Synopsys IP.
Support new versions 4.x and 5.x of Synopsys DesignWare Gigabit
Ethernet MAC, often referred to as DWC Quality-of-Service IP Core.
In particular:
- version 5_30 (0x53) that is found on stm32mp2 arm64 SoC
- version 5_40 (0x54) that is found on Spacemit K3 RISC-V RVA23 SoC
DWC Ethernet QoS introduced a new scalable multi-channel architecture
with up to eight TX/RX channels, enhanced DCB support, TCP segmentation
offload (TSO).
Thanks to manu@ for start splitting out the DMA code of the older
(dwc version 3.x) driver to separate files in 2023. This patch is
a continuation of that work to support new core and DMA engine.
Thanks to mmel@ for initial review. Initial support covers the same
interface capabilities as the version 3 (VLAN_MTU, HWCSUM, HWCSUM_IPV6).
[5 lines not shown]
[clang][bytecode] Fix initializer-list edge cases (#227587)
Namely, initializer lists for primitive types and discarding the result
of an initializer list.
[MLIR][Remark] Make remark reporting thread-safe and order final remarks by source position
Passes nested under the multithreaded pass manager report into the same
RemarkEngine from worker threads, but nothing in the engine or the
policies was synchronized. RemarkEmittingPolicyFinal inserted into its
map from several threads at once, and under RemarkEmittingPolicyAll the
streamer, including the LLVM remark serializer, was called from several
threads at once. ThreadSanitizer reports both races in the new unit tests.
RemarkEngine now holds a lock around every call into the policy. It is a
recursive llvm::sys::SmartMutex, the same type as the DiagnosticEngine's
lock. report() takes it, and so does a new finalizePolicy(), which the
engine destructor and mlir-opt now use instead of calling finalize() on
the policy directly. For the All policy the streamer and the diagnostic
printer also run under the lock, so custom policies and streamers need no
lock of their own.
With the race fixed, the final policy's creation order is still not
deterministic: which thread reports first depends on scheduling.
[16 lines not shown]
[MLIR][Remark] Emit final-policy remarks in deterministic order
RemarkEmittingPolicyFinal stores remarks in a DenseSet whose hash covers the
location pointer and the hash seed, so finalize() emitted them in bucket
order, which depends on the build and on where things landed in memory. That
is why mlir/test/Pass/remark-final.mlir used CHECK-DAG.
The engine assigns every remark a RemarkId from a monotonic counter when it is
created, and the set already keeps the newer of two remarks with the same
identity. finalize() now sorts the drained remarks by that ID before emitting,
so remarks come out in creation order and a replaced identity takes the
position of its last report. Linked remarks still follow their parent.
Order only. The identity, DenseMapInfo<Remark> and the header are unchanged.
Only remarks handed to the policy outside the engine have no ID; the unit
tests that do so assert unordered or single results.
Assisted-by: Claude Code (Claude Fable 5.1)
net/samba42[234Ø: fix on ZFS STATUS_INTERNAL_ERROR, Input/output error from vfs_freebsd.c
Replace strlcpy() to memmove() in vfs_freebsd.c.
PR: 292618
Reported by: Dave Baukus <daveb at spectralogic.com>
Sponsored by: Klara, Inc
security/openssl30: Resurrect OpenSSL 3.0 port
For FreeBSD 14, expires 2028-11-30
Has known vulnerabilities, users are encouraged to move
to OpenSSL 3.5 from security/openssl
[lldb][Windows] Lock the thread list when lldb-server accesses it (#226974)
`NativeProcessProtocol::Threads()` returns a `LockingAdaptedIterable`
that holds `m_threads_mutex` for the lifetime of the iteration, so
callers may hold references into `m_threads` across the loop body. On
Windows, this is only done when removing threads:
```
// OnCreateThread
m_threads.push_back(std::move(thread));
...
// OnExitThread
std::lock_guard<std::recursive_mutex> guard(m_threads_mutex);
llvm::erase_if(m_threads, ...);
```
`m_threads` is a `std::vector<std::unique_ptr<NativeThreadProtocol>>`.
When the debug-event thread appends and the vector reallocates, every
reference held by a concurrent iteration on the main loop dangles. This
[17 lines not shown]
sys/qwz: unwind cold startup failures
Based on sys/dev/ic/qwx.c,v 1.134
Track powerup and completed core initialization so failed cold starts
reset hardware before reclaiming initialized DMA resources. Release
partial TX allocations and RX rings; ordinary interface down and up
continues to retain firmware.
OK: stsp@
