FreeBSD/src 62fbb17sys/kern imgact_elf.c

imgact_elf: Unconditionally initialize a variable in a note handler

In the sb == NULL case, we are computing the size of the note using a
dummy sbuf drain handler which counts bytes and discards the contents of
the buffer, so the fact that "structsize" is uninitialized doesn't
matter.  But, the compiler may complain about this, so we might as well
just initialize it unconditionally to silence the warning, as other
handlers already do.

PR:             292811
MFC after:      1 week

(cherry picked from commit 8a68c2509c00ae0dbeab64064bb600cfac787a73)
DeltaFile
+1-1sys/kern/imgact_elf.c
+1-11 files

LLVM/project 9908a04llvm/test/CodeGen/AMDGPU maximumnum.bf16.ll minimumnum.bf16.ll, llvm/test/CodeGen/RISCV/rvv vfma-vp.ll

Rebase, simplify

Created using spr 1.3.7
DeltaFile
+18,621-0llvm/test/CodeGen/Thumb2/mve-clmul.ll
+4,582-5,914llvm/test/CodeGen/RISCV/rvv/vfma-vp.ll
+6,877-0llvm/test/tools/llvm-mca/AArch64/Cortex/C1Ultra-sve-instructions.s
+3,326-2,794llvm/test/CodeGen/AMDGPU/maximumnum.bf16.ll
+3,326-2,794llvm/test/CodeGen/AMDGPU/minimumnum.bf16.ll
+5,336-0llvm/test/tools/llvm-mca/AArch64/Cortex/C1Ultra-writeback.s
+42,068-11,5022,068 files not shown
+204,878-67,6932,074 files

LLVM/project 9e45a7aclang/lib/CodeGen CGExpr.cpp, clang/test/OpenMP target_indirect_codegen.cpp

[clang][OpenMP] Fix __llvm_omp_indirect_call_lookup signature for targets with non-default program AS (#192470)

The argument and return value for `__llvm_omp_indirect_call_lookup` are
function pointers so make sure they are in the correct address space.

Signed-off-by: Nick Sarnie <nick.sarnie at intel.com>
DeltaFile
+5-4clang/lib/CodeGen/CGExpr.cpp
+3-2clang/test/OpenMP/target_indirect_codegen.cpp
+8-62 files

FreeBSD/src b77bd0esys/compat/freebsd32 freebsd32_misc.c

freebsd32: Fix freebsd11_nstat copyout condition

freebsd11_freebsd32_nstat() invoked copyout(2) when
freebsd11_cvtnstat32() failed and skipped copyout on success. This is
backwards.

Fix this to match freebsd11_freebsd32_nlstat() and freebsd11_nstat(),
and only copy the nstat32 result to userspace when conversion succeeds.

Signed-off-by:  Weixie Cui <cuiweixie at gmail.com>
Reviewed by:    mhorne
MFC after:      1 week
Pull Request:   https://github.com/freebsd/freebsd-src/pull/2109

(cherry picked from commit c6224994ac70b4f71ef9e11903bb2e50ed2b1bfe)
DeltaFile
+1-1sys/compat/freebsd32/freebsd32_misc.c
+1-11 files

FreeBSD/src 95d6612share/man/man9 malloc.9

malloc.9: adjust flag table indentation

The current indentation is shorter than all but one of these flags. This
renders much more nicely.

MFC after:      3 days

(cherry picked from commit be79a42275cad21c6087d8bbd6a328735ea813fa)
DeltaFile
+1-1share/man/man9/malloc.9
+1-11 files

FreeBSD/doc 577feb9website/content/en/status/report-2026-01-2026-03 bugmeister.adoc

Status/2026Q1/bugmeister.adoc: Add report

Differential Revision:  https://reviews.freebsd.org/D56181
DeltaFile
+21-0website/content/en/status/report-2026-01-2026-03/bugmeister.adoc
+21-01 files

FreeBSD/src ce33f96sys/dev/mlx5/mlx5_en mlx5_en_main.c

mlx5e: Ensure rx timestamps are monotonically increasing

The clock calibration routine currently can result in rx timestamps
jumping backwards, which can confuse the TCP stack.
Ensure they are monotonically increasing by estimating what
we'd calculate as the next timestamp and clamp the calibration
so new timestamps are no earlier in time.

Reviewed by: kib, nickbanks_netflix.com
Tested by: nickbanks_netflix.com
Differential Revision: https://reviews.freebsd.org/D56427
Sponsored by: Netflix
DeltaFile
+50-0sys/dev/mlx5/mlx5_en/mlx5_en_main.c
+50-01 files

FreeBSD/doc 4f9d23awebsite/content/en/status/report-2026-01-2026-03 sbom.adoc

Status/2026Q1/sbom.adoc: Add report

Reviewed by:    status (Graham Percival <gperciva at tarsnap.com>)
Differential Revision:  https://reviews.freebsd.org/D56299
DeltaFile
+37-0website/content/en/status/report-2026-01-2026-03/sbom.adoc
+37-01 files

LLVM/project ffde06fllvm/include/llvm/Transforms Utils.h, llvm/include/llvm/Transforms/Utils StripConvergenceIntrinsics.h

[NFC][SPIRV] Move `SPIRVStripConvergenceIntrinsics` to Utils (#188537)

The `SPIRVStripConvergenceIntrinsic` pass was written as a spirv pass as
it is the currently the only target that emits convergence tokens during
codegen. There is nothing target specific to the pass, and, we plan to
emit convergence tokens when targeting DirectX (and all targets in
general), so move the pass to a common place.

The previous pass used temporary `Undef`s, as part of moving the pass we
can simply reverse the traverse order to remove the use of `Undef` as it
is deprecated.

Enables the pass for targeting DirectX and is a pre-req for:
https://github.com/llvm/llvm-project/pull/188792.

Assisted by: Github Copilot
DeltaFile
+99-0llvm/lib/Transforms/Utils/StripConvergenceIntrinsics.cpp
+0-86llvm/lib/Target/SPIRV/SPIRVStripConvergentIntrinsics.cpp
+79-0llvm/test/Transforms/StripConvergenceIntrinsics/basic.ll
+38-0llvm/test/CodeGen/DirectX/strip-convergence-intrinsics.ll
+29-0llvm/include/llvm/Transforms/Utils/StripConvergenceIntrinsics.h
+7-0llvm/include/llvm/Transforms/Utils.h
+252-8610 files not shown
+265-9316 files

LLVM/project 4dd1632

[MCP][NFC] Opinionated refactoring

There are a few minor inconsistencies across the pass which I found mildly
distracting:

* The use of `Def`/`Dest`/`Dst` to refer to the same thing
* Inconsistent declaration order of `Dst`/`Src` vs `Src`/`Dst`
* Lots of `->getReg()->asMCReg()`, and uses of `Register` when the pass
  is always running after RA anyway.
* Some places explicitly `assert(isCopyInstr)` while others just deref
  the `optional`.

Standardize on `Dst`/`Src` to match the metaphor and ordering of
`DestSourcePair`.

Assume `std::optional::operator*` will assert in any reasonable
implementation, even though this may technically be undefined behavior.
When asserts are disabled it would be anyway.


    [11 lines not shown]
DeltaFile
+0-00 files

LLVM/project 92faf52llvm/lib/CodeGen MachineCopyPropagation.cpp, llvm/test/CodeGen/X86 machine-copy-prop.mir

[MCP] Never eliminate frame-setup/destroy instructions

Presumably targets only insert frame instructions which are significant,
and there may be effects MCP doesn't model. Similar to reserved registers this
is probably overly conservative, but as this causes no codegen change in
any lit test I think it is benign.

The motivation is just to clean up #183149 for AMDGPU, as we can spill
to physical registers, and currently have to spill the EXEC mask purely
to enable debug-info.

Change-Id: I9ea4a09b34464c43322edd2900361bf635efd9f7
DeltaFile
+22-0llvm/test/CodeGen/X86/machine-copy-prop.mir
+11-5llvm/lib/CodeGen/MachineCopyPropagation.cpp
+33-52 files

LLVM/project 2f8d3ea

[MCP][NFC] Cleanup and prepare to preserve frame-setup/destroy

This mixes renames, removing redundant code, avoiding
`else`-after-`return`, etc. with factoring out the `isNeverRedundant`
concept.

Change-Id: I43a62a9415019cdd63c68fd3b915ebb7505d317a
DeltaFile
+0-00 files

FreeBSD/ports 49fa297ports-mgmt/pkg distinfo

ports-mgmt/pkg: better with distinfo
DeltaFile
+3-3ports-mgmt/pkg/distinfo
+3-31 files

LLVM/project dcfe195llvm/lib/CodeGen MachineCopyPropagation.cpp

[MCP][NFC] Opinionated refactoring (#186239)

There are a few minor inconsistencies across the pass which I found mildly distracting:

* The use of `Def`/`Dest`/`Dst` to refer to the same thing
* Inconsistent declaration order of `Dst`/`Src` vs `Src`/`Dst`
* Lots of `->getReg()->asMCReg()`, and uses of `Register` when the pass
  is always running after RA anyway.
* Some places explicitly `assert(isCopyInstr)` while others just deref
  the `optional`.

Standardize on `Dst`/`Src` to match the metaphor and ordering of
`DestSourcePair`.

Assume `std::optional::operator*` will assert in any reasonable
implementation, even though this may technically be undefined behavior.
When asserts are disabled it would be anyway.

The refactor uses structured bindings for a couple reasons:

    [9 lines not shown]
DeltaFile
+163-194llvm/lib/CodeGen/MachineCopyPropagation.cpp
+163-1941 files

LLVM/project 7aa2b04llvm/lib/Target/X86 X86ISelLowering.cpp, llvm/test/CodeGen/X86 stack-clash-dynamic-alloca.ll stack-clash-small-alloc-medium-align.ll

[X86] Use unsigned comparison for stack clash probing loop (#192355)

The stack clash probing loop generated in `EmitLoweredProbedAlloca` used
a signed comparison (`X86::COND_GE`) to determine when the allocation
target had been reached.

In 32-bit mode, memory addresses above `0x80000000` have the sign bit
set. If the stack pointer lands in this region, treating the addresses
as signed integers causes the comparison logic to fail. This leads to
incorrect loop execution, resulting in an infinite loop and a crash
(segmentation fault) when setting up custom stacks for pthreads mapped
above `0x80000000` in a 32b process.

This patch changes the condition code to `X86::COND_AE` (Above or
Equal), which generates an unsigned comparison. This ensures that
addresses are treated correctly as unsigned quantities on all targets.

On 64-bit systems, this change has no practical effect on valid
user-space addresses because they do not use the sign bit (being

    [4 lines not shown]
DeltaFile
+4-4llvm/test/CodeGen/X86/stack-clash-dynamic-alloca.ll
+2-2llvm/test/CodeGen/X86/stack-clash-small-alloc-medium-align.ll
+1-1llvm/lib/Target/X86/X86ISelLowering.cpp
+7-73 files

FreeBSD/src ce6b497sys/arm/broadcom/bcm2835 raspberrypi_virtgpio.c

raspberry_virtgpio: fix OF_hasprop() usage

The function returns a bool. This driver was merged recently (by me) and
I missed this instance.

While here, adjust the ofw_bus_status_okay() call similarly. This
function still returns an int, but this usage is more widely used in our
drivers.

No functional change intended.

MFC after:      3 days
Sponsored by:   The FreeBSD Foundation
Fixes:          b60cd486a652 ("ofw: bool-ify OF_hasprop()")
DeltaFile
+2-2sys/arm/broadcom/bcm2835/raspberrypi_virtgpio.c
+2-21 files

FreeBSD/src 47b0ac1share/man/man9 OF_getprop.9

OF_getprop.9: update OF_hasprop() signature

The return type has been converted to a bool.

Reported by:    manu
Sponsored by:   The FreeBSD Foundation
Fixes:          b60cd486a652 ("ofw: bool-ify OF_hasprop()")
DeltaFile
+8-4share/man/man9/OF_getprop.9
+8-41 files

LLVM/project 1317890clang/lib/CIR/CodeGen CIRGenBuiltinAArch64.cpp, clang/test/CodeGen/AArch64 neon-intrinsics.c

[CIR][AArch64] Lower NEON vrsra_n intrinsics (#191129)

### Summary
Implement CIR lowering for all intrinsics in
https://arm-software.github.io/acle/neon_intrinsics/advsimd.html#vector-rounding-shift-right-and-accumulate

This PR references the implementation from the ClangIR incubator:
https://github.com/llvm/clangir/blob/main/clang/lib/CIR/CodeGen/CIRGenBuiltinAArch64.cpp#L4854

AArch64 does not provide a dedicated "rounding shift right by immediate"
instruction. Instead, the `SRSHL` / `URSHL` intrinsics take a signed
per-lane shift amount where a negative value means right shift, so an
immediate right shift by `n` is encoded as a signed vector splat of
`-n`. The three infrastructure changes below exist to support this
encoding at the call site:

- extends `emitNeonShiftVector` with a `neg` parameter so the
right-shift-as-negative-left-shift encoding is handled inside the
helper;

    [8 lines not shown]
DeltaFile
+317-0clang/test/CodeGen/AArch64/neon/intrinsics.c
+0-245clang/test/CodeGen/AArch64/neon-intrinsics.c
+71-21clang/lib/CIR/CodeGen/CIRGenBuiltinAArch64.cpp
+388-2663 files

FreeBSD/doc b843a2cwebsite/content/en/status/report-2026-01-2026-03 pkgbasify.adoc

Status/2026Q1/pkgbasify.adoc: Add report

Reviewed by:    status (Graham Percival <gperciva at tarsnap.com>)
Differential Revision:  https://reviews.freebsd.org/D56302
DeltaFile
+13-0website/content/en/status/report-2026-01-2026-03/pkgbasify.adoc
+13-01 files

LLVM/project a81621allvm/lib/Target/AMDGPU AMDGPURegBankLegalizeRules.cpp, llvm/test/CodeGen/AMDGPU llvm.amdgcn.perm.pk.ll

AMDGPU/GlobalISel: RegBankLegalize rules for perm_pk16_b{4,6,8}_u4 (#192368)
DeltaFile
+95-1llvm/test/CodeGen/AMDGPU/llvm.amdgcn.perm.pk.ll
+12-0llvm/lib/Target/AMDGPU/AMDGPURegBankLegalizeRules.cpp
+107-12 files

FreeBSD/doc c9304ffwebsite/content/en/status/report-2026-01-2026-03 h616.adoc jumbograms.adoc

Status/2026Q1: Add two reports

Reviewed by:    status (Graham Percival <gperciva at tarsnap.com>)
Differential Revision:  https://reviews.freebsd.org/D56388
DeltaFile
+13-0website/content/en/status/report-2026-01-2026-03/h616.adoc
+11-0website/content/en/status/report-2026-01-2026-03/jumbograms.adoc
+24-02 files

LLVM/project fbbb8c1flang/test/Evaluate rewrite09.f90

Remove empty trailing lines
DeltaFile
+0-2flang/test/Evaluate/rewrite09.f90
+0-21 files

FreeBSD/ports 11a1518devel/p5-Log-Dispatch-File-Rolling Makefile, devel/p5-Log-Dispatch-File-Rolling/files patch-lib_Log_Dispatch_File_Rolling.pm

devel/p5-Log-Dispatch-File-Rolling: patch for perl 5.40

The attached patch fixes this message:

Attempt to call undefined import method with arguments ("2.37")
via package "Log::Dispatch::File" (Perhaps you forgot to load the
package?) at /usr/local/lib/perl5/site_perl/Log/Dispatch/File/Rolling.pm line 8.

PR:             288790
Approved by:    maintainer timeout (8 months)
DeltaFile
+10-1devel/p5-Log-Dispatch-File-Rolling/files/patch-lib_Log_Dispatch_File_Rolling.pm
+1-1devel/p5-Log-Dispatch-File-Rolling/Makefile
+11-22 files

LLVM/project 1b433e9mlir/include/mlir/Dialect/OpenACC OpenACCCGOps.td, mlir/lib/Dialect/OpenACC/IR OpenACCCG.cpp

[mlir][acc] Add canonicalization patterns for compute_region (#192376)

This PR improves the APIs for navigating through acc.compute_region
block arguments and also adds canonicalization patterns for those
arguments to remove unused ones and merge duplicates.
DeltaFile
+111-2mlir/lib/Dialect/OpenACC/IR/OpenACCCG.cpp
+78-0mlir/test/Dialect/OpenACC/compute-region-canonicalize.mlir
+17-2mlir/include/mlir/Dialect/OpenACC/OpenACCCGOps.td
+5-0mlir/unittests/Dialect/OpenACC/OpenACCUtilsCGTest.cpp
+2-0mlir/lib/Dialect/OpenACC/Utils/OpenACCUtils.cpp
+213-45 files

LLVM/project 5938bc1flang/test/Evaluate rewrite09.f90

Add test file
DeltaFile
+51-0flang/test/Evaluate/rewrite09.f90
+51-01 files

FreeBSD/doc b3675bewebsite/content/en/status/report-2026-01-2026-03 gcc.adoc

Status/2026Q1/gcc.adoc: Add report

Reviewed by:    status (Graham Percival <gperciva at tarsnap.com>)
Differential Revision:  https://reviews.freebsd.org/D56378
DeltaFile
+25-0website/content/en/status/report-2026-01-2026-03/gcc.adoc
+25-01 files

FreeBSD/ports b199a8dports-mgmt/pkg pkg-plist Makefile

ports-mgmt/pkg: update to 2.7.4

- repo: do not delete repositories in overrides, simply disable them
- query: fix %y/%Y
- Declare CheriBSD and CheriABI OS and ABI
DeltaFile
+2-2ports-mgmt/pkg/pkg-plist
+1-1ports-mgmt/pkg/Makefile
+3-32 files

FreeBSD/ports 12dc3fctextproc/py-zensical Makefile distinfo

textproc/py-zensical: Update to 0.0.33

Approved by:    kai
Changelog:      https://github.com/zensical/zensical/releases/tag/v0.0.33
Differential Revision:  https://reviews.freebsd.org/D56418
DeltaFile
+3-3textproc/py-zensical/Makefile
+3-3textproc/py-zensical/distinfo
+6-62 files

FreeBSD/src 90fc383sys/amd64/amd64 pmap.c, sys/arm/arm pmap-v6.c

pmap: Do not use PMAP_LOCK_INIT with kernel_pmap

The kernel_pmap lock is a bit special: it does not need the DUPOK flag,
and it really belongs to a different lock class.  If it belongs to the
same class as regular pmap locks, then witness may report warnings when
performing UMA allocations under a regular pmap lock, if the allocation
triggers a pmap_growkernel() call.

Replace instances of PMAP_LOCK_INIT(kernel_pmap) with inline mtx_init()
calls to silence some witness warnings for harmless behaviour I see with
some uncommitted test programs.

Reviewed by:    alc, kib
MFC after:      2 weeks
Differential Revision:  https://reviews.freebsd.org/D56185

(cherry picked from commit c6a1c1260f02e44b7f44b1e3735ce5dbd785544d)
DeltaFile
+1-1sys/powerpc/booke/pmap.c
+1-1sys/riscv/riscv/pmap.c
+1-1sys/arm64/arm64/pmap.c
+1-1sys/amd64/amd64/pmap.c
+1-1sys/arm/arm/pmap-v6.c
+1-1sys/i386/i386/pmap.c
+6-63 files not shown
+9-99 files

FreeBSD/src 1379cdesys/kern imgact_elf.c

imgact_elf: Unconditionally initialize a variable in a note handler

In the sb == NULL case, we are computing the size of the note using a
dummy sbuf drain handler which counts bytes and discards the contents of
the buffer, so the fact that "structsize" is uninitialized doesn't
matter.  But, the compiler may complain about this, so we might as well
just initialize it unconditionally to silence the warning, as other
handlers already do.

PR:             292811
MFC after:      1 week

(cherry picked from commit 8a68c2509c00ae0dbeab64064bb600cfac787a73)
DeltaFile
+1-1sys/kern/imgact_elf.c
+1-11 files