[VPlan] Extract IV exit value from vector loop if predicates are needed. (#200020)
When an IV needs predicates (e.g. to make sure it does not wrap in a
narrower range), the precomputed end value would use the inductions
narrowed step, which can lead to incorrect results for the exiting value
outside the loop. For example consider a loop where IV has a predicate
to not wrap in i16 with the top 16 bits stripped (something like
https://llvm.godbolt.org/z/nzfoWbcEG).
Building on top of tracking the predicates per-IV
(https://github.com/llvm/llvm-project/pull/192876), we can simply
extract the exit values from the vector values in the loop.
Depends on https://github.com/llvm/llvm-project/pull/192876
PR: https://github.com/llvm/llvm-project/pull/200020
textproc/py-elasticsearch5: Remove expired port
2026-06-30 textproc/py-elasticsearch5: 5.x reached EoL, last version was in 2018 - use textproc/py-elasticsearch 9.3.0 instead
18195 Convert mpstat(8) to mdoc(7)
Reviewed by: Peter Tribble <peter.tribble at gmail.com>
Reviewed by: Toomas Soome <tsoome at me.com>
Approved by: Dan McDonald <danmcd at edgecast.io>
NAS-141612 / 26.0.0-RC.1 / pam_keyring: resolve UI cert via certificate.query on stable/26 (#19234)
services.certificate exists only on master's typed ServiceContainer, so
_resolve_ui_cert_pem raised AttributeError (swallowed by the best-effort
except) and the SCRAM-PLUS server binding was never published to the
keyring. Switch to call_sync('certificate.query') with dict access,
mirroring nginx.conf.mako.
Fixes test__scram_plus_server_binding_published and
test__login_with_api_key_over_tls_channel_binding.
devel/redasm: pending the update, unbreak the port's build
Relax REDasm::Emulator::remap() method access from private
to protected, as it is being called from the derived class,
and fix a minor GUI bug while I'm here.
There are newer versions available, but those have various
run-time (3.0.0-beta5 segfaults on start) or build (4.0.0-
beta1 is a massive rewrite) issues to be taken care of.
Reported by: pkg-fallout
[lldb] Add accelerator plugin connection support (#201449)
Summary
This builds on the accelerator plugin protocol
(https://github.com/llvm/llvm-project/pull/201489) by letting a plugin
ask the client to create and connect a second
target — the mechanism a real backend (e.g. a GPU debug stub) uses to
surface
the accelerator alongside the CPU process being debugged.
### What this adds
**Protocol** — a new `AcceleratorConnectionInfo` describing how the
client
should bring up the accelerator target.
**Client** — when an `AcceleratorActions` carries `connect_info`,
`ProcessGDBRemote` creates a new (empty) target, reverse-connects it to
[143 lines not shown]
