[lldb/test] Skip TestBranchIslands on remote targets (#203068)
The test builds four 120 MB padding object files and links them into
a.out specifically to force the linker to emit an arm64 branch island
between main() and foo(). On a remote target the resulting ~480 MB
binary has to be uploaded byte-by-byte over gdb-remote vFile:write,
which on its own consumes the bulk of the lit timeout budget before any
debugging work happens; the test then times out at 600s.
The test verifies a host-toolchain artifact (the linker's branch island
generation), not anything about the runtime; running it on-device adds
nothing. Skip on remote.
Signed-off-by: Med Ismail Bennani <ismail at bennani.ma>
[NFC][SpecialCaseList] Add findRule helpers (#203025)
Introduce findRule helpers to RegexMatcher, GlobMatcher, and Matcher.
These helpers find the rule name matching a given line number.
This is a non-functional change (NFC) and will be used in a subsequent
commit to provide better warning messages when deprecated dot-slash
matching is triggered.
Assisted-by: Gemini
security/zeek: Unbreak build for current after 86326398b73b
Upstream issue:
https://github.com/zeek/zeek/issues/5557
Upstream analysis:
In C++20 which we use assert is still a mess since it is so
underspecified, but many implementations already perform
conversion of its arguments to bool; this is likely the reason
we missed this. According to your logs the implementation of
assert in your particular build configuration does not do that
Upstream fixes:
https://github.com/zeek/spicy/pull/2399
Do not assume assert performs C++26 contextual conversions
[6 lines not shown]
[AArch64] Minor rearrangement of cost instructions. NFC (#203080)
This just moves the existing cost checks to a more standard order and
cleans up
how v2i64 is processed.
[AMDGPU] Avoid errors with 23-bit division and remainder. (#202753)
Extensive testing of expandDivRem24 found an error when calculating Y/X
when Y = (0x7FFFFF/X)*X-1. There are
36 values of X for which this happens. Limit expansion to 23-bit signed
and 22-bit unsigned to avoid this issue.
Testing added in https://github.com/llvm/llvm-test-suite/pull/419.
---------
Signed-off-by: John Lu <John.Lu at amd.com>
net/xfr: update to 0.9.16
[0.9.16] - 2026-06-10
v0.9.15 was tagged but never released: its release CI failed on the aarch64-gnu cross build (glibc < 2.27 lacks the memfd_create wrapper; now invoked via raw syscall). All v0.9.15 changes ship here.
Fixed
-R UDP no longer reports the server's send rate as throughput (issue #81) — in download mode the server is the UDP sender, and both the live intervals and the final result carried its bytes_sent: every send_to the kernel accepted counted, so over a constrained link the display tracked the requested -b rate (brettowe's 999.7 Mbps over 100 Mbps Wi-Fi) instead of what arrived. The client — the receiver, the only side that knows wire truth — now overlays its own receive counters onto live intervals (TUI, --json-stream, CSV, plain) and the final result (total, per-stream, throughput). Forward mode was always correct because there the server is the receiver. Repro: CPU-starved receiver with a 4 KB receive buffer showed 2.6 Gbps sender-side vs 1.18 Gbps actually received; the display previously claimed the former and now reports the latter, exactly matching received-packets × packet-size.
-R UDP results now include loss and jitter — the client's receive_udp already computed full receiver-side UdpStats (loss %, jitter, out-of-order, max jitter) but discarded them; download mode showed no UDP Stats block at all. They're now recorded and attached to the final result, and live loss in download mode is derived from the client's own packet trackers rather than the server's (empty) receiver counters.
Added
Zero-copy TCP sends (-Z/--zerocopy, Linux) (issue #33) — the send payload now lives in a memfd_create anonymous file and is pushed to the socket with sendfile(2), skipping the userspace-to-kernel copy that write(2) performs on every 128 KB chunk. On CPU-bound senders (embedded routers, SBCs) the copy itself is often the throughput bottleneck — iperf3's equivalent -Z measured ~3x on a MIPS router. sendfile was chosen over MSG_ZEROCOPY for the first step because it works on old kernels, needs no error-queue completion reaping, and is MPTCP-compatible; MSG_ZEROCOPY remains on the roadmap under the same flag. Opt-in, TCP-only (conflicts with -u/-Q at parse time), and never fails a test: non-Linux platforms, kernels without memfd_create, and sockets that reject sendfile all fall back to regular writes with a warning. Payload semantics are unchanged (--random default / --zeros fill the memfd exactly as they fill the regular buffer).
zerocopy_v1 capability + TestStart.zerocopy field — for -R/--bidir, the client forwards the zero-copy request in TestStart (wire-additive, absent = false) and the server applies it to its own send paths. Servers predating the field silently ignore it, so the client warns when the server doesn't advertise zerocopy_v1.
Library API (pre-1.0 break)
tcp::TcpConfig and client::ClientConfig gain zerocopy: bool. Struct-literal constructors must supply it (Default is false).
[7 lines not shown]
devel/gitpane: update to 0.7.14
[0.7.14] - 2026-06-09
Added
- The submodule tag in the Changes panel now shows which branch the submodule is on (@<branch>,
or @detached for a detached HEAD, which is git's default after submodule update), so a dirty
or modified submodule tells you where the change lives. It also gains a ↛main warning when
the pinned submodule commit is reachable from a remote but not from the submodule's default
branch (origin/HEAD, falling back to origin/main/origin/master), meaning it still needs a merge
there. The warning stays silent when no default branch resolves, so it never fires on a false
positive. The existing ⚠unreach (commit on no remote) still takes precedence, while ↑N (ahead
of upstream) and ↛main compose, e.g. [sub: +commit @feature ↑3 ↛main].
[MLIR][XeGPU] Enable WG-level mxfp GEMM via generalized shape_cast collapse inference (#201496)
Summary
Bringing up two WG-level mxfp GEMM integration tests —
simple_mxfp_gemm_quantizeA_F4 and
simple_mxfp_gemm_dequantizeB_F4 — exposed several gaps in the XeGPU
layout-propagation and unroll paths
that previously kept them from compiling end-to-end. This PR lands those
two tests as the motivating
workloads, plus the supporting changes:
1. A generalized shape_cast collapse layout inference — required because
the mxfp lowering inserts
vector.shape_cast ops that collapse multiple src dims into a single dst
dim with non-trivial sg / lane
layouts spanning across them. The previous matchCollapseToInnermostDim
only covered the narrow […] →
[N] / [1, N] shape and could not infer correct source layouts for these
[104 lines not shown]
