FreeBSD/ports 05fc754net/ucx Makefile, net/ucx/files patch-src_ucs_vfs_fuse_vfs__fuse.c

net/ucx: Fix VFS inotify watch on FreeBSD

IN_IGNORED is generated when a watch is removed and should not be
included in the inotify_add_watch request mask. FreeBSD rejects that
mask with EINVAL.

Remove the FreeBSD error workaround, which returned UCS_OK and caused
the VFS thread to retry in a tight loop.

PR:             296182
Reported by:    thierry
Reviewed by:    thierry (mentor),
                Generic Rikka <rikka.goering at outlook.de> (maintainer)
Tested by:      thierry (mentor),
                Generic Rikka <rikka.goering at outlook.de> (maintainer)
Approved by:    thierry (mentor)
DeltaFile
+10-17net/ucx/files/patch-src_ucs_vfs_fuse_vfs__fuse.c
+1-1net/ucx/Makefile
+11-182 files

LLVM/project 036af90llvm/lib/Target/Hexagon HexagonExpandCondsets.cpp, llvm/test/CodeGen/Hexagon dont-predicate-debug.mir

[Hexagon] Avoid predicating debug instructions (#212917)

The change is made in HexagonExpandCondsets::(predicate) function. The
debug instructions are not predicable as they cannot be separated into
conditional branches. So while predicating instructions in a machine
basic block if we encounter any debug instructions we need to skip these
instructions and continue with other instructions.

The scan that collects the registers defined and used between the
definition of the source register and the conditional transfer bailed
out as soon as it saw a non-virtual register operand, which a DBG_VALUE
can have. The transfer was then left as an unconditional A2_asrh plus an
A2_tfrf instead of being folded into a single predicated A4_pasrhf, so
again the generated code differed depending on whether debug info was
enabled.

Co-authored-by: Chandana Sinderikeri <csinderi at qti.qualcomm.com>
DeltaFile
+59-0llvm/test/CodeGen/Hexagon/dont-predicate-debug.mir
+5-0llvm/lib/Target/Hexagon/HexagonExpandCondsets.cpp
+64-02 files

FreeNAS/freenas 86c526a. .gitignore, openspec config.yaml

Openspec specification for how current update system works
DeltaFile
+437-0openspec/specs/update-server-publishing/spec.md
+259-0openspec/specs/update-version-selection/spec.md
+233-0openspec/specs/update-profiles/spec.md
+8-0openspec/config.yaml
+1-0.gitignore
+938-05 files

LLVM/project 2a4acc4llvm/test/Transforms/SLPVectorizer/X86 reassociate-ops.ll

[SLP][NFC]Add extra test for alt opcodes vectorization with copyables, NFC



Reviewers: 

Pull Request: https://github.com/llvm/llvm-project/pull/213538
DeltaFile
+70-0llvm/test/Transforms/SLPVectorizer/X86/reassociate-ops.ll
+70-01 files

LLVM/project f383699llvm/test/Transforms/SLPVectorizer/X86 reassociate-ops.ll

[𝘀𝗽𝗿] initial version

Created using spr 1.3.7
DeltaFile
+70-0llvm/test/Transforms/SLPVectorizer/X86/reassociate-ops.ll
+70-01 files

LLVM/project eee7c2dllvm/docs ORCv2.md, llvm/include/llvm/ExecutionEngine/Orc COFFAutoImportGenerator.h

[ORC] Add AutoImportGenerator for COFF dllimport auto-import (#203914)

On Windows/COFF, a dllimport call is emitted as an indirect call through
an `__imp_` IAT slot (`callq *__imp_bar(%rip)`), and even a direct call
to a library function is expected to bind to a thunk supplied by an
import library. Today a JIT client must produce those import libraries
themselves. `AutoImportGenerator` synthesizes them on demand instead.

Bound to a single dynamic library via `AutoImportGenerator::Load(ES,
ObjLinkingLayer, "/path/to/lib.dll")`.
For each referenced export `X`, lazily synthesizes an `__imp_X` pointer
slot holding `X`'s address in the library plus an `X` thunk that jumps
through it, so both `__imp_`-mediated and direct references resolve.


The library's export table is the authority: a name the library does not
export is left unresolved, so the link fails exactly as a static link
against the corresponding import library would (no silent invention of
symbols).

    [23 lines not shown]
DeltaFile
+178-0llvm/unittests/ExecutionEngine/Orc/COFFAutoImportGeneratorTest.cpp
+132-0llvm/lib/ExecutionEngine/Orc/COFFAutoImportGenerator.cpp
+112-0llvm/include/llvm/ExecutionEngine/Orc/COFFAutoImportGenerator.h
+60-3llvm/tools/llvm-jitlink/llvm-jitlink.cpp
+39-0llvm/docs/ORCv2.md
+3-3llvm/lib/ExecutionEngine/JITLink/COFF_x86_64.cpp
+524-65 files not shown
+532-611 files

FreeNAS/freenas 628a4de.claude/commands/opsx archive.md, .claude/skills/openspec-explore SKILL.md

Openspec specification for how current update system works
DeltaFile
+437-0openspec/specs/update-server-publishing/spec.md
+296-0.claude/skills/openspec-explore/SKILL.md
+259-0openspec/specs/update-version-selection/spec.md
+225-0openspec/specs/update-profiles/spec.md
+223-0.claude/commands/opsx/archive.md
+223-0.claude/skills/openspec-sync-specs/SKILL.md
+1,663-010 files not shown
+3,035-016 files

NetBSD/src EsTnkDYetc/etc.evbarm Makefile.inc

   Fix indent.
VersionDeltaFile
1.142+6-6etc/etc.evbarm/Makefile.inc
+6-61 files

LLVM/project 9a19c77clang/lib/Driver/ToolChains NetBSD.h NetBSD.cpp, clang/test/Driver netbsd.cpp

[clang][Driver] Fix libc++ include path on NetBSD (#212716)

`clang++` defaults to `-stdlib=libc++` on NetBSD. When building with
both `clang` and `libcxx` included, the freshly built `clang++` fails to
find `<__config_site>`:

```
In file included from /usr/include/strings.h:68:
In file included from bin/../include/c++/v1/string.h:57:
bin/../include/c++/v1/__config:13:10: fatal
error: '__config_site' file not found
   13 | #include <__config_site>
      |          ^~~~~~~~~~~~~~~
```

The file is present in `include/<triplet>/c++/v1`, but that isn't
searched by default. NetBSD has its own version of addLibCxxIncludePaths
which misses that directory.


    [9 lines not shown]
DeltaFile
+0-21clang/lib/Driver/ToolChains/NetBSD.cpp
+8-0clang/test/Driver/netbsd.cpp
+0-3clang/lib/Driver/ToolChains/NetBSD.h
+0-0clang/test/Driver/Inputs/install_tree_with_libcxx/lib/.keep
+0-0clang/test/Driver/Inputs/install_tree_with_libcxx/include/c++/v1/.keep
+0-0clang/test/Driver/Inputs/install_tree_with_libcxx/bin/.keep
+8-246 files

NetBSD/pkgsrc iErW3Cgdoc pkg-vulnerabilities

   clear three pkgs
VersionDeltaFile
1.773+4-4doc/pkg-vulnerabilities
+4-41 files

NetBSD/pkgsrc CYzR82sdoc CHANGES-2026

   doc: Updated shells/oh-my-posh to 30.2.0
VersionDeltaFile
1.4903+2-1doc/CHANGES-2026
+2-11 files

NetBSD/pkgsrc iJISVXNshells/oh-my-posh Makefile go-modules.mk

   shells/oh-my-posh: update to 30.2.0

   v30.2.0
   Bug Fixes

       studio: drop stray text under segment preview (42b9f83)

   Features

       config: offer pwd OSC values in schema (8a3a06f)
       studio: rebuild config editor on CodeMirror 6 (c53ff0d)

   v30.1.1
   Bug Fixes

       template: block network and DoS-capable functions from untrusted templates (7e224b2)
       template: scope env var access to trusted templates only (9edb5b7)
       terminal: satisfy fieldalignment in iterm test cases (7bfd50b)
       terminal: strip control runes from OSC pwd/iterm sequences (16bf138)

    [5 lines not shown]
VersionDeltaFile
1.320+4-160shells/oh-my-posh/distinfo
1.139+0-52shells/oh-my-posh/go-modules.mk
1.352+2-2shells/oh-my-posh/Makefile
+6-2143 files

FreeBSD/src a5a16basys/fs/nullfs null_vnops.c

nullfs: close a race when syncing inotify flags from the lower vnode

After a bypassed VOP, nullfs mirrors the lower vnode's inotify state
onto the upper vnode.  The flags were checked with lockless reads
before being updated with the asserting flag set/unset primitives, so
two threads syncing the same vnode concurrently (or a sync racing a
watch being established) could both decide to make the same change;
the loser then trips the "flags already set" assertion on an
INVARIANTS kernel.  On other kernels the race is harmless.

Keep the lockless check as the fast path, but re-make the decision
under the vnode interlock before actually changing the flags.

Reproduced in a 4-CPU VM with one thread cycling an inotify watch on
a lower-filesystem file while several threads stat(2) the same file
through a nullfs mount: the unpatched INVARIANTS kernel panics under
this load, the patched kernel runs it to completion.

Fixes:                  f1f230439fa4 ("vfs: Initial revision of inotify")

    [6 lines not shown]
DeltaFile
+14-5sys/fs/nullfs/null_vnops.c
+14-51 files

FreeBSD/src f68d7bflib/libc/stdlib strfromd.c strfroml.c, lib/libc/tests/stdlib strfrom_test.c

libc: Add strfromd, strfromf, and strfroml per C23

strfromd(), strfromf(), and strfroml() are implemented directly
in terms of gdtoa.  If a non-conforming format string is passed,
the string "EDOOFUS" is returned and errno set to EDOOFUS as an
extension.

Reviewed by:    fuz
MFC after:      1 month
Pull-Request:   https://github.com/freebsd/freebsd-src/pull/2301
Signed-off-by:  Faraz Vahedi <kfv at kfv.io>
DeltaFile
+590-0lib/libc/tests/stdlib/strfrom_test.c
+476-0lib/libc/stdlib/strfrom.c
+109-0lib/libc/stdlib/strfromd.3
+47-0lib/libc/stdlib/strfromf.c
+46-0lib/libc/stdlib/strfroml.c
+45-0lib/libc/stdlib/strfromd.c
+1,313-05 files not shown
+1,363-111 files

LLVM/project 4695d91llvm/include/llvm/ExecutionEngine/Orc/RTBridge Calls.h, llvm/include/llvm/ExecutionEngine/Orc/RTBridge/SPS Calls.h

[ORC] Generalize RTBridge Callers to any runtime function (#213526)

An RTBridge Caller is a controller-side handle for calling a function in
the runtime. Until now the abstraction assumed every such function was a
trampoline -- a runtime function whose job is to invoke *another*
function at an address the controller supplies (run-as-main, run-as-int,
etc.) -- so every Caller carried a dedicated ExecutorAddr parameter for
that target.

Generalize Callers to call runtime functions of any shape. Invoking a
supplied target is now just one kind of call, with the target address an
ordinary leading argument rather than a built-in parameter: e.g.
MainCaller becomes Caller<int64_t(ExecutorAddr, ArrayRef<std::string>)>.

The SPS signatures already led with an SPSExecutorAddr for the target,
so this is a pure interface change -- the SPS wrappers and all call
sites are unaffected. It lets Callers model runtime functions that do
the work themselves, such as the memory-access wrappers, rather than
only those that dispatch to another function.
DeltaFile
+15-16llvm/include/llvm/ExecutionEngine/Orc/RTBridge/Calls.h
+8-9llvm/include/llvm/ExecutionEngine/Orc/RTBridge/SPS/Calls.h
+23-252 files

LLVM/project 29a956eclang/include/clang/Options Options.td, clang/lib/CodeGen CGOpenMPRuntimeGPU.cpp

[offload][OpenMP] Add atomic cross-team reductions (#209298)

Regular cross-team reductions have two phases: the intra-team reduction
and the inter-team reduction. Atomic cross-team reductions replace the
second phase with a atomic instruction which is used by the main thread
of each team to directly fold the result of the intra-team reduction
into the final result. Since this requires a combination of "data type"
and "combine operation" for which an atomic instruction is available,
only some (but very common) reductions can be transformed to atomic
reductions. In cases where multiple reductions are performed on the same
construct, the atomic path is only taken if all reductions can be
transformed. Otherwise, we fall back to the regular cross-team reduction
using a buffer with per-team slots. This is not strictly necessary, but
hybrid reductions would induce more complexity with questionable
benefit.

Selecting an atomic path might not be the best option for every
situation, which is why it is not enabled by default. Instead, it can be
enabled via `-fopenmp-target-atomic-reduction`. Note that enabling the

    [17 lines not shown]
DeltaFile
+107-2clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
+90-0clang/test/OpenMP/target_teams_atomic_reduction_codegen.cpp
+64-0offload/test/offloading/xteam_atomic_reduction_usm.cpp
+32-0llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
+18-0clang/test/Driver/openmp-target-atomic-reduction-flag.c
+9-0clang/include/clang/Options/Options.td
+320-26 files not shown
+340-212 files

HardenedBSD/src 0834609usr.sbin/bhyve bhyve_config.5

Merge branch 'freebsd/15-stable/main' into hardened/15-stable/main
DeltaFile
+19-9usr.sbin/bhyve/bhyve_config.5
+19-91 files

HardenedBSD/ports 48409a1databases/rocksdb/files patch-cmake_RocksDBConfig.cmake.in RocksDBTargets.cmake, devel/cargo-readme distinfo

Merge branch 'freebsd/main' into hardenedbsd/main
DeltaFile
+16-666math/deal.ii/pkg-plist
+113-0databases/rocksdb/files/RocksDBTargets.cmake
+110-0lang/sbcl/files/patch-contrib_sb-manual_texinfo.lisp
+85-0databases/rocksdb/files/patch-cmake_RocksDBConfig.cmake.in
+29-25devel/cargo-readme/distinfo
+15-17net-mgmt/py-napalm/Makefile
+368-70846 files not shown
+616-82452 files

NetBSD/src rTF9BqYcrypto/external/bsd/openssh/dist sshd-session.c

   Add a blocklist probe (Jose Luis Duran)
VersionDeltaFile
1.15+5-3crypto/external/bsd/openssh/dist/sshd-session.c
+5-31 files

LLVM/project b1e21e2llvm/lib/Transforms/Vectorize VPlanTransforms.h VPlanTransforms.cpp, llvm/test/Transforms/LoopVectorize find-last-iv-sinkable-expr.ll

[VPlan] Handle step where sign cannot be determined optimizeFindIVRed. (#213450)

optimizeFindIVReductions uses the step to determine if min or max is
needed. Bail out if the direction of the step cannot be determined via
SCEV.

Fixes https://github.com/llvm/llvm-project/issues/213424
DeltaFile
+112-0llvm/test/Transforms/LoopVectorize/find-last-iv-sinkable-expr.ll
+25-12llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
+3-1llvm/lib/Transforms/Vectorize/VPlanTransforms.h
+140-133 files

NetBSD/pkgsrc 471INdVdoc CHANGES-2026

   Updated lang/py-libcst, devel/py-vcs-versioning
VersionDeltaFile
1.4902+3-1doc/CHANGES-2026
+3-11 files

NetBSD/pkgsrc oheJ78adevel/py-vcs-versioning Makefile distinfo

   py-vcs-versioning: updated to 2.2.3

   2.2.3 (2026-07-28)

   Fixed

   - Fix `ValueError` when parsing `.git_archival.txt` of a tagged commit whose tag contains more than one dash (e.g. `llvmorg-23.1.0-rc2`) - the `git describe` suffix is now matched precisely instead of splitting on the last two dashes.
VersionDeltaFile
1.7+4-4devel/py-vcs-versioning/distinfo
1.8+2-2devel/py-vcs-versioning/Makefile
+6-62 files

NetBSD/pkgsrc ownqkSklang/py-libcst PLIST Makefile

   py-libcst: updated to 1.9.0

   1.9.0 - 2026-07-29

   Added
   * Add support for Python 3.15
   * Add `CodemodCommand` helpers for adding and removing imports

   Fixed
   * Recognize Python 3.14 parser configurations
   * Allow a trailing comma after `**rest` in class patterns

   Updated
   * Document the new `CodemodCommand` import helpers
   * Fix the `tokenize` function's docstring grammar
   * Remove the retired macOS 13 runner from CI
VersionDeltaFile
1.22+22-31lang/py-libcst/distinfo
1.15+6-9lang/py-libcst/cargo-depends.mk
1.28+3-3lang/py-libcst/Makefile
1.14+4-1lang/py-libcst/PLIST
+35-444 files

FreeBSD/src ae417b3lib/msun/ld128 s_asinpil.c, lib/msun/ld80 s_atanpil.c s_asinpil.c

msun: add asinpi, acospi, and atanpi

This commit implements the inverse half-cycle
trigonometric functions:

   asinpi(x) = asin(x) / pi                        Eq. (1)
   acospi(x) = acos(x) / pi
   atanpi(x) = atan(x) / pi

Implemention details are contained in src/s_asinpi.c and
src/a_atanpi.c, where the details for acospi(x) appear in
the former.

*************

CAVEAT EMPTOR: The ld128 code has been only compiled.  It has
not been tested for correctness due to lack of hardware.

*************

    [125 lines not shown]
DeltaFile
+243-0lib/msun/src/s_asinpi.c
+215-0lib/msun/src/s_atanpi.c
+191-0lib/msun/ld80/s_asinpil.c
+175-0lib/msun/ld80/s_atanpil.c
+173-0lib/msun/ld128/s_asinpil.c
+157-0lib/msun/src/s_asinpif.c
+1,154-09 files not shown
+1,735-1515 files

FreeBSD/src 00a7997lib/libc/stdlib merge.c

libc/merge.c: use memcpy() for copying

Currently mergesort() uses ICOPY_*() to copy data as four byte blocks
instead of one byte. However, this is only achievable when both size and
base arguments are aligned to four bytes.

Use of memcpy() is ideal as 1) it is cleaner and 2) the library will use
SIMD for copying when the hardware supports it. Compared to ICOPY_*(),
SIMD can support up to 64 bytes. When the SIMD-backed memcpy() find the
address is unaligned, it can first copy data up to the nearest aligned
address, and then use SIMD operations for faster transfer. Thus memcpy()
can give better performance than mergesort()'s own implementation.

This is benchmarked on amd64 where there isn't a SIMD-backed
implementation yet. However, the baseline implementation in assembly
already delivers better performance in unaligned cases although there is
some performance drops in aligned cases. The benchmark results and
script is available in the Phabricator review. Ideally, more performance
improvements will come when amd64 gets SIMD implementation of memcpy().

    [5 lines not shown]
DeltaFile
+21-48lib/libc/stdlib/merge.c
+21-481 files

FreeBSD/src 296c05flib/libutil++ libutil++.hh

libutil++: Include <cerrno> in stringf.cc

stringf.cc uses errno and related macros without including <cerrno>.

Their availability is guaranteed only when the corresponding header
is included; transitive exposure is implementation-defined.

Modern libc++ has been progressively reducing incidental transitive
includes as part of its header removal policy (see LLVM libc++ Header
Removal Policy and D132284), making such dependencies brittle.

This change includes <cerrno> explicitly to make the dependency
well-defined. No functional or behavioural change intended.

Approved by:    fuz
Signed-off-by:  Faraz Vahedi <kfv at kfv.io>
Pull-Request:   https://github.com/freebsd/freebsd-src/pull/2188
DeltaFile
+1-0lib/libutil++/libutil++.hh
+1-01 files

LLVM/project 4e924a6lldb/source/Expression IRExecutionUnit.cpp

[lldb] std::move unique_ptrs, rather than calling .release. (#213525)

These .release() calls are legacy from the std::auto_ptr to
std::unique_ptr transition.
DeltaFile
+2-2lldb/source/Expression/IRExecutionUnit.cpp
+2-21 files

HardenedBSD/src afb2563usr.sbin/bhyve bhyve_config.5

bhyve: tidy up bhyve_config.5

There are few warnings reported by mandoc -Tlint:

bhyve_config.5:255:31: WARNING: new sentence, new line
bhyve_config.5:257:43: WARNING: new sentence, new line
bhyve_config.5:422:2: WARNING: missing section argument: Xr nm_open
bhyve_config.5:469:24: WARNING: skipping no-space macro
bhyve_config.5:483:2: WARNING: wrong number of cells: 2 columns, 4 cells
bhyve_config.5:484:2: WARNING: wrong number of cells: 2 columns, 4 cells
bhyve_config.5:541:24: WARNING: skipping no-space macro

 - "new sentence, new line" is a trivial formatting fix.
 - "missing section": there is actually no nm_open() manual page,
    so use .Nm instead of .Xr for it.
 - "no-space macro": format without .Oc and .Ns, similarly to
    how it is already done in bhyve.8 for VNC addresses.
 - "wrong number of cells": also a trivial fix.


    [6 lines not shown]
DeltaFile
+19-9usr.sbin/bhyve/bhyve_config.5
+19-91 files

FreeBSD/src afb2563usr.sbin/bhyve bhyve_config.5

bhyve: tidy up bhyve_config.5

There are few warnings reported by mandoc -Tlint:

bhyve_config.5:255:31: WARNING: new sentence, new line
bhyve_config.5:257:43: WARNING: new sentence, new line
bhyve_config.5:422:2: WARNING: missing section argument: Xr nm_open
bhyve_config.5:469:24: WARNING: skipping no-space macro
bhyve_config.5:483:2: WARNING: wrong number of cells: 2 columns, 4 cells
bhyve_config.5:484:2: WARNING: wrong number of cells: 2 columns, 4 cells
bhyve_config.5:541:24: WARNING: skipping no-space macro

 - "new sentence, new line" is a trivial formatting fix.
 - "missing section": there is actually no nm_open() manual page,
    so use .Nm instead of .Xr for it.
 - "no-space macro": format without .Oc and .Ns, similarly to
    how it is already done in bhyve.8 for VNC addresses.
 - "wrong number of cells": also a trivial fix.


    [6 lines not shown]
DeltaFile
+19-9usr.sbin/bhyve/bhyve_config.5
+19-91 files

LLVM/project e096d2flld/COFF Chunks.h Driver.cpp, lld/test/COFF arm64x-tls.s

[LLD][COFF] Replace ARM64EC TLS directory chunks with native chunks when available (#212845)

On ARM64X targets, CRT provides separate TLS directory chunks, expecting
the linker to sort it out. TLS directory uses _tls_start and _tls_end
symbols to reference .tls section. Those symbols use section sorting to
ensure that they are emitted at the start and end of .tls section, but that's
not enough when we have two separate chunks for views: only one of them
can really be the first one. Following MSVC, merge those chunks instead so
that both symbol tables point to the same chunk.

Additionally apply the same logic to _tls_used and _tls_index. This
allows entire TLS directory to be shared between EC and native views. To
achieve that, CRT additionally needs to mark each TLS callback with
-arm64xsameaddress. This matches how MSVC linker and libraries work, but
it requires EC and native views to use the same set of TLS callbacks. We
may emit separate TLS directories in the future to make it more robust.
DeltaFile
+121-0lld/test/COFF/arm64x-tls.s
+24-3lld/COFF/Driver.cpp
+2-1lld/COFF/Chunks.h
+147-43 files