FreeBSD/ports 4c4a2c2textproc/oyo distinfo Makefile.crates

textproc/oyo: Update to 0.1.34

ChangeLog:      https://github.com/ahkohd/oyo/releases/tag/v0.1.34
Reported by:    "github-actions[bot]" <notifications at github.com>
DeltaFile
+13-3textproc/oyo/distinfo
+5-0textproc/oyo/Makefile.crates
+2-2textproc/oyo/Makefile
+20-53 files

NetBSD/pkgsrc-wip b5d2398ipv6calc Makefile

ipv6calc: Solve REPLACE_BASH for .sh/sh.in files
DeltaFile
+8-2ipv6calc/Makefile
+8-21 files

LLVM/project 32ecd3ellvm/lib/Transforms/Scalar LoopInterchange.cpp, llvm/test/Transforms/LoopInterchange non-phi-uses-lcssa-phi.ll

[LoopInterchange] Bail out when outer loop latch PHI has non-PHI user (#201923)

When there are non-PHI instructions in the outer loop that use values
originating from the LCSSA PHIs of the inner loop, it becomes difficult
to adjust the wiring during the transformation. In fact, multiple issues
(#200819 and #201571) have been raised related to this pattern. #201059
tried to resolve the issue by modifying the transformation phase, but it
was insufficient.
Instead of spending effort in the transformation phase, this patch adds
an additional check in the legality check and rejects such cases. I
think the cases rejected by this additional check are not very
practical, so the impact on realistic cases should be low, and it is
simpler than adjusting the wiring in the transformation phase.
This patch also effectively reverts #201059, as it is no longer
necessary.

Fix #201571.
DeltaFile
+74-24llvm/test/Transforms/LoopInterchange/non-phi-uses-lcssa-phi.ll
+22-4llvm/lib/Transforms/Scalar/LoopInterchange.cpp
+96-282 files

LLVM/project fee67eellvm/lib/Target/X86 X86FlagsCopyLowering.cpp, llvm/test/CodeGen/X86 flags-copy-lowering-unreachable.mir

[X86] Don't assert on EFLAGS copies in unreachable blocks (#203208)

X86FlagsCopyLowering collects the EFLAGS copies to lower using a
ReversePostOrderTraversal, which only visits blocks reachable from the
entry. Its end-of-pass verification, however, iterated over every block
in the function, so an EFLAGS copy left in an unreachable block (e.g.
produced by ISel for an always-taken branch whose other edge is dead)
tripped the "Unlowered EFLAGS copy!" assertion.

Such copies are harmless: the unreachable block is removed by the
unreachable-block elimination pass that runs right after this one,
before register allocation, so the copy never reaches a pass that cannot
handle it. Restrict the verification to reachable blocks (depth_first
from the entry) to match the set of blocks actually processed.

Found via fuzzing (llvm-isel-fuzzer).
DeltaFile
+29-0llvm/test/CodeGen/X86/flags-copy-lowering-unreachable.mir
+3-2llvm/lib/Target/X86/X86FlagsCopyLowering.cpp
+32-22 files

FreeNAS/freenas 1b2a93bsrc/middlewared/middlewared/api/v26_0_0 reporting.py, src/middlewared/middlewared/plugins/reporting graphs.py

Remove stale ARC graph names from reporting API

`reporting.get_data` accepted three graph names — `arcrate`, `arcactualrate`, `arcresult` — whose backing plugin classes were deleted during the ZFS netdata plugin rewrite. The Pydantic `Literal` and the in-memory `__graphs` dict drifted out of sync, so passing any of them crashed `netdata_get_data` with an uncaught `KeyError`.

Removed the dead names from `GraphIdentifier.name`'s `Literal` and docstring in both `v26_0_0/reporting.py` and `v27_0_0/reporting.py`. Added a `ReportingNetdataGetDataArgs.from_previous` on each so legacy WS clients walking the adapter chain get the dead entries silently filtered instead of a hard rejection at the final v27 boundary. Hardened the dispatch site in `plugins/reporting/graphs.py` to raise `CallError(ENOENT)` for any unknown name — mirroring what `netdata_graph` already does — so future schema/implementation drift surfaces as a clean RPC error rather than an unhandled exception.
DeltaFile
+85-0src/middlewared/middlewared/pytest/unit/api/handler/version/test_reporting_graph_filter.py
+10-5src/middlewared/middlewared/api/v26_0_0/reporting.py
+4-1src/middlewared/middlewared/plugins/reporting/graphs.py
+99-63 files

FreeNAS/freenas 155f84esrc/middlewared/middlewared/api/v27_0_0 reporting.py

v27 pydantic changes
DeltaFile
+2-5src/middlewared/middlewared/api/v27_0_0/reporting.py
+2-51 files

LLVM/project e5b82f4cross-project-tests/debuginfo-tests/dexter/dex/debugger DAP.py

format
DeltaFile
+5-1cross-project-tests/debuginfo-tests/dexter/dex/debugger/DAP.py
+5-11 files

LLVM/project f4a0273lldb/test/API/tools/lldb-dap/coreFile TestDAP_coreFile.py, lldb/tools/lldb-dap/Handler AttachRequestHandler.cpp

[lldb-dap] Support loading core files through attachCommands (#202785)

The `attachCommands` attach option lets users bootstrap a session with
arbitrary LLDB commands, but a command that loaded a core (e.g. `target
create --core`) produced a broken session:
`ConfigurationDoneRequestHandler` would call `process.Continue()` on the
core and fail, because the non-live-session handling was keyed on the
`coreFile` attach argument rather than on the actual resulting process.

This teaches `AttachRequestHandler` to detect, after the attach commands
run, whether the selected process was loaded from a core via the
`SBProcess:: IsLiveDebugSession()` API added in #203111. When it is a
core, it sets `stop_at_entry` and clears `is_live_session`, mirroring
what the `coreFile` key does.
DeltaFile
+91-41lldb/test/API/tools/lldb-dap/coreFile/TestDAP_coreFile.py
+9-0lldb/tools/lldb-dap/Handler/AttachRequestHandler.cpp
+100-412 files

LLVM/project 9d98437llvm/include/llvm/ADT StringMap.h, llvm/lib/Transforms/IPO StripSymbols.cpp

[StringMap] Invalidate iterators in remove() (#203249)

erase() bumps the epoch to invalidate iterators (#202237), but the
lower-level remove() — which detaches an entry without destroying it,
used
by ValueSymbolTable via Value::setName() — did not. Move the
incrementEpoch() into remove() so remove-while-iterating fails fast
under
LLVM_ENABLE_ABI_BREAKING_CHECKS too.

Aided by Claude Opus 4.8
Reland after lldb fix #203035
DeltaFile
+10-7llvm/lib/Transforms/IPO/StripSymbols.cpp
+11-0llvm/unittests/ADT/StringMapTest.cpp
+4-2llvm/include/llvm/ADT/StringMap.h
+25-93 files

FreeBSD/ports e3ca324net/rustconn distinfo Makefile.crates

net/rustconn: Update to 0.15.14

ChangeLog:

- https://github.com/totoshko88/RustConn/releases/tag/v0.15.13
- https://github.com/totoshko88/RustConn/releases/tag/v0.15.14

Reported by:    "github-actions[bot]" <notifications at github.com>
DeltaFile
+17-15net/rustconn/distinfo
+7-6net/rustconn/Makefile.crates
+1-1net/rustconn/Makefile
+25-223 files

LLVM/project 831ed97mlir/docs LangRef.md

[mlir][LangRef] Clarify terminator continuations (#201111)

Document that terminators may have no normal control-flow continuation,
such as ub.unreachable. Also clarify that no-return calls do not remove
the structural terminator requirement.

Assisted-by: Codex
DeltaFile
+24-17mlir/docs/LangRef.md
+24-171 files

LLVM/project 625538fllvm/lib/Support KnownBits.cpp, llvm/unittests/Support KnownBitsTest.cpp

[KnownBits] Fix add() SelfAdd assertion for bitwidths >= 512 (#202769)

`KnownBits::add()` with `SelfAdd=true` lowers `X+X` to `shl(X, 1)` using
a fixed 8-bit shift amount:

```cpp
KnownBits Amt = KnownBits::makeConstant(APInt(8, 1));
return KnownBits::shl(LHS, Amt, NUW, NSW, /*ShAmtNonZero=*/true);
```

The comment there claims the shift-amount bitwidth is independent of the
source bitwidth, but that is not true: `shl()`'s `getMaxShiftAmount()`
extracts `Log2_32(BitWidth)` bits from the shift amount's max value when
`BitWidth` is a power of two:

```cpp
static unsigned getMaxShiftAmount(const APInt &MaxValue, unsigned BitWidth) {
  if (isPowerOf2_32(BitWidth))
    return MaxValue.extractBitsAsZExtValue(Log2_32(BitWidth), 0);

    [23 lines not shown]
DeltaFile
+19-0llvm/unittests/Support/KnownBitsTest.cpp
+4-1llvm/lib/Support/KnownBits.cpp
+23-12 files

LLVM/project 534e92allvm/lib/Transforms/Scalar LoopInterchange.cpp

address review
DeltaFile
+1-3llvm/lib/Transforms/Scalar/LoopInterchange.cpp
+1-31 files

LLVM/project 495d2adllvm/lib/Transforms/Scalar LoopInterchange.cpp, llvm/test/Transforms/LoopInterchange reduction-extra-use-in-inner-loop.ll

[LoopInterchange] Reject if outer reduction value has extra user
DeltaFile
+13-23llvm/test/Transforms/LoopInterchange/reduction-extra-use-in-inner-loop.ll
+20-0llvm/lib/Transforms/Scalar/LoopInterchange.cpp
+33-232 files

LLVM/project 2a1767cllvm/test/Transforms/LoopInterchange reduction-extra-use-in-inner-loop.ll

[LoopInterchange] Add test for extra reduction use in inner loop (NFC)
DeltaFile
+281-0llvm/test/Transforms/LoopInterchange/reduction-extra-use-in-inner-loop.ll
+281-01 files

LLVM/project 4976526llvm/lib/Transforms/Scalar LoopInterchange.cpp, llvm/test/Transforms/LoopInterchange inner-induciton-step-is-not-invariant.ll

[LoopInterchange] Reject if inner loop IV has outer-variant step
DeltaFile
+20-48llvm/test/Transforms/LoopInterchange/inner-induciton-step-is-not-invariant.ll
+7-1llvm/lib/Transforms/Scalar/LoopInterchange.cpp
+27-492 files

LLVM/project b603297llvm/lib/Transforms/Scalar LoopInterchange.cpp, llvm/test/Transforms/LoopInterchange reduction2mem-limitation.ll

[LoopInterchange] Consolidate induction and reduction vars check
DeltaFile
+72-95llvm/lib/Transforms/Scalar/LoopInterchange.cpp
+4-10llvm/test/Transforms/LoopInterchange/reduction2mem-limitation.ll
+76-1052 files

LLVM/project 072c355llvm/test/Transforms/LoopInterchange inner-induciton-step-is-not-invariant.ll

[LoopInterchange] Add tests for outer-variant inner IV step (NFC) (#202750)

Adds test cases for #202383 and #202401. Both have an induction variable
in the inner loop whose step value is not loop-invariant with respect to
the outer loop.
DeltaFile
+147-0llvm/test/Transforms/LoopInterchange/inner-induciton-step-is-not-invariant.ll
+147-01 files

LLVM/project b1d7986llvm/lib/Target/AMDGPU SIInsertWaitcnts.cpp AMDGPUWaitcntUtils.cpp, llvm/lib/Target/AMDGPU/Utils AMDGPUBaseInfo.cpp AMDGPUBaseInfo.h

[NFC][AMDGPU][InsertWaitCnts] Move some simple functions into Utils

Move really trivial functions into helpers to declutter InsertWaitCnt a bit more.
I had to move HardwareLimits into a different header but it's only used in InsertWaitCnt so it doesn't matter.
DeltaFile
+21-86llvm/lib/Target/AMDGPU/SIInsertWaitcnts.cpp
+75-0llvm/lib/Target/AMDGPU/AMDGPUWaitcntUtils.cpp
+32-0llvm/lib/Target/AMDGPU/AMDGPUWaitcntUtils.h
+0-20llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp
+0-20llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.h
+128-1265 files

LLVM/project f026978llvm/lib/Target/AMDGPU SIInsertWaitcnts.cpp, llvm/test/CodeGen/AMDGPU waitcnt-debug.mir

[RFC][AMDGPU] Remove DebugCounter-based WaitCnt debugging

It's 8 years old, only used by a handful of tests, and has not been updated
in a while except for maintenance as far as I can see.

I don't mind keeping it in if there are users of it, but right now it
looks like a dead feature. If we want some more elaborate waitcnt debugging,
we should have a modern, generic system that works on any waitcnt, not
something specific to 3 GFX9 counters.
DeltaFile
+1-50llvm/lib/Target/AMDGPU/SIInsertWaitcnts.cpp
+0-44llvm/test/CodeGen/AMDGPU/waitcnt-debug.mir
+1-942 files

LLVM/project dc4bb6dllvm/lib/Target/AMDGPU/Utils AMDGPUHWEvents.h

fmt
DeltaFile
+2-1llvm/lib/Target/AMDGPU/Utils/AMDGPUHWEvents.h
+2-11 files

LLVM/project 65daf7bllvm/lib/Target/AMDGPU/Utils AMDGPUHWEvents.cpp AMDGPUHWEvents.h

Comment
DeltaFile
+0-5llvm/lib/Target/AMDGPU/Utils/AMDGPUHWEvents.cpp
+3-1llvm/lib/Target/AMDGPU/Utils/AMDGPUHWEvents.h
+3-62 files

LLVM/project 4482096llvm/lib/Target/AMDGPU SIInsertWaitcnts.cpp

delete function i missed
DeltaFile
+0-40llvm/lib/Target/AMDGPU/SIInsertWaitcnts.cpp
+0-401 files

LLVM/project 556ad5bllvm/lib/Target/AMDGPU AMDGPUHWEvents.cpp SIInsertWaitcnts.cpp

[AMDGPU][InsertWaitCnts] Move HWEvent analysis code

Building up on the previous RFC, if it is accepted:
Move the code that maps a MachineInstr to HWEventSet to a separate file.

This should be NFC.
DeltaFile
+164-0llvm/lib/Target/AMDGPU/AMDGPUHWEvents.cpp
+3-116llvm/lib/Target/AMDGPU/SIInsertWaitcnts.cpp
+6-0llvm/lib/Target/AMDGPU/AMDGPUHWEvents.h
+173-1163 files

LLVM/project 414a267llvm/lib/Target/AMDGPU AMDGPUHWEvents.h AMDGPUHWEvents.def, llvm/lib/Target/AMDGPU/Utils AMDGPUHWEvents.h AMDGPUHWEvents.def

Move files
DeltaFile
+0-120llvm/lib/Target/AMDGPU/Utils/AMDGPUHWEvents.h
+120-0llvm/lib/Target/AMDGPU/AMDGPUHWEvents.h
+0-65llvm/lib/Target/AMDGPU/Utils/AMDGPUHWEvents.def
+65-0llvm/lib/Target/AMDGPU/AMDGPUHWEvents.def
+29-0llvm/lib/Target/AMDGPU/AMDGPUHWEvents.cpp
+0-29llvm/lib/Target/AMDGPU/Utils/AMDGPUHWEvents.cpp
+214-2143 files not shown
+216-2169 files

LLVM/project 0f2599bllvm/lib/Target/AMDGPU SIInsertWaitcnts.cpp, llvm/lib/Target/AMDGPU/Utils AMDGPUHWEvents.h AMDGPUHWEvents.def

[RFC][AMDGPU][InsertWaitCnt] Move WaitEventType into separate HWEvent header

I propose to move `WaitEventType` into its own header to start a new
component of the back-end targeted at analyzing and treating hardware events
fired by instructions. Right now this just moves code around and renames things
(NFCI) but over time, we should generalize the events so they can be reused
by other passes instead of being hyper-specialized for InsertWaitCnt.
DeltaFile
+143-257llvm/lib/Target/AMDGPU/SIInsertWaitcnts.cpp
+117-0llvm/lib/Target/AMDGPU/Utils/AMDGPUHWEvents.h
+65-0llvm/lib/Target/AMDGPU/Utils/AMDGPUHWEvents.def
+34-0llvm/lib/Target/AMDGPU/Utils/AMDGPUHWEvents.cpp
+1-0llvm/lib/Target/AMDGPU/Utils/CMakeLists.txt
+360-2575 files

LLVM/project 8d79c5cllvm/lib/Target/AMDGPU AMDGPUHWEvents.cpp AMDGPUHWEvents.h

Make HWEventSet ctor non-explicit
DeltaFile
+17-17llvm/lib/Target/AMDGPU/AMDGPUHWEvents.cpp
+1-1llvm/lib/Target/AMDGPU/AMDGPUHWEvents.h
+18-182 files

LLVM/project 9f43acallvm/lib/Target/AMDGPU AMDGPUHWEvents.cpp

Comment
DeltaFile
+11-14llvm/lib/Target/AMDGPU/AMDGPUHWEvents.cpp
+11-141 files

LLVM/project 7527a0allvm/lib/Target/AMDGPU AMDGPUHWEvents.h SIInsertWaitcnts.cpp

Comments
DeltaFile
+2-0llvm/lib/Target/AMDGPU/AMDGPUHWEvents.h
+0-1llvm/lib/Target/AMDGPU/SIInsertWaitcnts.cpp
+2-12 files

LLVM/project 0cdf26dllvm/lib/Target/AMDGPU AMDGPUHWEvents.cpp

Comments
DeltaFile
+86-70llvm/lib/Target/AMDGPU/AMDGPUHWEvents.cpp
+86-701 files