FreeBSD/ports dc73a6enet Makefile, net/rubygem-oauth-gitlab Makefile

www/gitlab: fix regression by de79e0fe79131da57d98504a8871a94f75af43e9

it cause deinstallation of gitlab:
Checking integrity... done (2 conflicting)
  - rubygem-anonymous_loader-0.1.3 [gitlab] conflicts with rubygem-anonymous_loader-gitlab-0.1.3 [installed] on /usr/local/lib/ruby/gems/3.4/gems/anonymous_loader-0.1.3/CHANGELOG.md
  - rubygem-auth-sanitizer-0.2.3 [gitlab] conflicts with rubygem-auth-sanitizer-gitlab-0.2.3 [installed] on /usr/local/lib/ruby/gems/3.4/gems/auth-sanitizer-0.2.3/CHANGELOG.md
...
Installed packages to be REMOVED:
        gitlab-ce: 19.3.0
...
DeltaFile
+25-0net/rubygem-oauth-tty-gitlab/Makefile
+3-2net/rubygem-oauth-gitlab/Makefile
+3-0net/rubygem-oauth-tty-gitlab/distinfo
+2-0net/rubygem-oauth-tty-gitlab/pkg-descr
+1-0net/Makefile
+34-25 files

LLVM/project 1a864ballvm/lib/Target/RISCV RISCVFrameLowering.cpp, llvm/test/CodeGen/RISCV sifive-interrupt-frame-flags.ll

[RISCV] Mark SiFive CLIC epilogue instructions as frame-destroy (#218338)

SiFive CLIC interrupt epilogue instructions were incorrectly marked as
`FrameSetup`. This commit marks the restore sequence and final stack
swap as `FrameDestroy`.
DeltaFile
+30-0llvm/test/CodeGen/RISCV/sifive-interrupt-frame-flags.ll
+10-9llvm/lib/Target/RISCV/RISCVFrameLowering.cpp
+40-92 files

LLVM/project 9511dd7llvm/test/CodeGen/Mips llvm.sincos.f128.ll llvm.sincos.ll, llvm/test/CodeGen/X86 fp80-math-no-libcall-error.ll fp80-conv-libcalls.ll

RuntimeLibcalls: Fix wrongly typed x87/fp128 long double libcalls on x86 (#216979)

The x86 and default libcall sets gated the l-suffixed long double libm
functions on OS conditions rather than the long double format. This
incorrectly provided the f80 libcalls on targets whose long double is
not x87 (Windows-MSVC, UEFI, x86_64 Android), double-provided 
frexpl/ldexpl on musl, and provided the fp128 sincosl on targets using 
double as long double.

Gate the l-suffixed libm math on the long double format, mirroring the
earlier AArch64 fix: x87 targets get the _f80 calls, fp128 targets the _f128
calls, and double targets neither. The compiler-rt f80 helpers (__extendxftf2,
__fixxfti, __powixf2, ...) are keyed to the x86_fp80 IR type, not the long double
format, so they stay unconditional on x86.


Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
DeltaFile
+374-0llvm/test/CodeGen/X86/fp80-math-libcalls.ll
+0-359llvm/test/CodeGen/X86/finite-libcalls.ll
+0-266llvm/test/CodeGen/Mips/llvm.sincos.ll
+146-0llvm/test/CodeGen/X86/fp80-conv-libcalls.ll
+104-0llvm/test/CodeGen/X86/fp80-math-no-libcall-error.ll
+78-0llvm/test/CodeGen/Mips/llvm.sincos.f128.ll
+702-6254 files not shown
+771-65010 files

HardenedBSD/src e038f30sys/conf files.powerpc, sys/dev/dpaa fman_port_var.h fman_port_tx.c

Merge remote-tracking branch 'rad/hardened/current/master' into hardened/current/pledge
DeltaFile
+18-630sys/dev/dpaa/fman_port.c
+398-0sys/dev/dpaa/fman_port_rx.c
+347-0sys/dev/dpaa/fman_port_tx.c
+85-0sys/dev/dpaa/fman_port_var.h
+1-1sys/powerpc/include/slb.h
+2-0sys/conf/files.powerpc
+851-6316 files

HardenedBSD/src b9c522bsys/dev/e1000 e1000_82571.c e1000_mac.c, sys/dev/sound/pci hdspe-pcm.c

Merge remote-tracking branch 'rad/hardened/15-stable/main' into hardened/15-stable/pledge
DeltaFile
+137-84sys/dev/e1000/e1000_phy.c
+128-18sys/dev/e1000/e1000_ich8lan.c
+124-2sys/dev/e1000/e1000_i210.c
+54-46sys/dev/e1000/e1000_mac.c
+72-24sys/dev/sound/pci/hdspe-pcm.c
+63-5sys/dev/e1000/e1000_82571.c
+578-17923 files not shown
+724-23729 files

HardenedBSD/src bf36bb6sys/conf files.powerpc, sys/dev/dpaa fman_port_var.h fman_port_tx.c

Merge branch 'freebsd/current/main' into hardened/current/master
DeltaFile
+18-630sys/dev/dpaa/fman_port.c
+398-0sys/dev/dpaa/fman_port_rx.c
+347-0sys/dev/dpaa/fman_port_tx.c
+85-0sys/dev/dpaa/fman_port_var.h
+1-1sys/powerpc/include/slb.h
+2-0sys/conf/files.powerpc
+851-6316 files

HardenedBSD/src ffc778fsys/dev/e1000 e1000_82571.c e1000_mac.c, sys/dev/sound/pci hdspe-pcm.c

Merge branch 'freebsd/15-stable/main' into hardened/15-stable/main
DeltaFile
+137-84sys/dev/e1000/e1000_phy.c
+128-18sys/dev/e1000/e1000_ich8lan.c
+124-2sys/dev/e1000/e1000_i210.c
+54-46sys/dev/e1000/e1000_mac.c
+72-24sys/dev/sound/pci/hdspe-pcm.c
+63-5sys/dev/e1000/e1000_82571.c
+578-17923 files not shown
+724-23729 files

HardenedBSD/ports d217595editors/emacs Makefile, games/lwjgl3 distinfo

Merge branch 'freebsd/main' into hardenedbsd/main
DeltaFile
+52-0misc/codex/files/patch-codex-rs_core_src_tools_runtimes_apply_patch.rs
+7-7games/lwjgl3/distinfo
+8-3editors/emacs/Makefile
+5-5sysutils/zpool-set/distinfo
+5-5sysutils/zfs-set/distinfo
+5-5sysutils/zfs-allow/distinfo
+82-2542 files not shown
+170-9648 files

LLVM/project 62a903eflang/lib/Optimizer/CodeGen CodeGen.cpp, flang/test/Fir global-initialization.fir

[flang][CodeGen] Fix element type of folded insert_on_range initializers

`GlobalOpConversion` folds a full-range `fir.insert_on_range` into a dense
constant. When the inserted value comes from a `fir.convert`, the fold reached
through the conversion and built the dense attribute from the type of the
*source* constant. For a `logical(4)` array initialized to `.true.` this
produced

  llvm.mlir.constant(dense<true> : vector<32768xi1>) : !llvm.array<32768 x i32>

where the attribute element type `i1` disagrees with the result element type
`i32`. Translation to LLVM IR ignores the attribute type and uses the result
type, so the emitted global is still correct today, but the IR is malformed and
any consumer that trusts the attribute type sees the wrong element width.

Build the dense attribute from the converted element type instead. A logical
conversion normalizes its operand to a canonical 0/1 (see `ConvertOpConversion`),
so apply the same normalization here; any other mismatching conversion is left
to the regular lowering.

    [2 lines not shown]
DeltaFile
+25-5flang/lib/Optimizer/CodeGen/CodeGen.cpp
+1-1flang/test/Fir/global-initialization.fir
+26-62 files

FreeBSD/ports 71943ebwww/nginx-acme Makefile distinfo, www/nginx-devel version.mk Makefile

www/nginx-devel: Update to 1.31.4

*) Feature: the "proxy_protocol" directive in the stream and mail
   modules now supports the PROXY protocol version 2.

*) Change: now HTTP/2 and gRPC requests to backends are always sent with
   the ":authority" pseudo-header, and HTTP/1.1 requests - with the
   "Host" header.

*) Bugfix: a segmentation fault might occur in a worker process if the
   "select" method was used.

*) Bugfix: incomplete gRPC responses with a non-zero "Content-Length"
   header line are now treated as malformed.

*) Bugfix: in binary compatibility with third-party modules using script
   codes; the bug had appeared in 1.31.3.

*) Bugfix: in the ngx_http_perl_module.

    [7 lines not shown]
DeltaFile
+2-4www/nginx-devel/Makefile
+3-3www/nginx-devel/distinfo
+3-3www/nginx-acme/distinfo
+1-1www/nginx-devel/version.mk
+1-0www/nginx-acme/Makefile
+10-115 files

HardenedBSD/ports 71943ebwww/nginx-acme Makefile distinfo, www/nginx-devel version.mk Makefile

www/nginx-devel: Update to 1.31.4

*) Feature: the "proxy_protocol" directive in the stream and mail
   modules now supports the PROXY protocol version 2.

*) Change: now HTTP/2 and gRPC requests to backends are always sent with
   the ":authority" pseudo-header, and HTTP/1.1 requests - with the
   "Host" header.

*) Bugfix: a segmentation fault might occur in a worker process if the
   "select" method was used.

*) Bugfix: incomplete gRPC responses with a non-zero "Content-Length"
   header line are now treated as malformed.

*) Bugfix: in binary compatibility with third-party modules using script
   codes; the bug had appeared in 1.31.3.

*) Bugfix: in the ngx_http_perl_module.

    [7 lines not shown]
DeltaFile
+2-4www/nginx-devel/Makefile
+3-3www/nginx-devel/distinfo
+3-3www/nginx-acme/distinfo
+1-1www/nginx-devel/version.mk
+1-0www/nginx-acme/Makefile
+10-115 files

LLVM/project a75788fllvm/lib/Target/AMDGPU GCNSubtarget.h

Fix typo

Co-authored-by: Lukas Sommer <lukas.sommer at amd.com>
DeltaFile
+1-1llvm/lib/Target/AMDGPU/GCNSubtarget.h
+1-11 files

LLVM/project 14e04bcllvm/lib/Transforms/Vectorize LoopVectorizationPlanner.h VPlanTransforms.cpp, llvm/test/Transforms/LoopVectorize/RISCV tail-folding-complex-mask.ll

[VPlan] Append recipes created via builder to worklist

The previous PR appended the top most created recipe to the worklist, and this PR extends it to any other nested recipes that were created, similar to InstCombine.

This removes the header mask in a good few more places on RISC-V as measured on SPEC CPU 2017, e.g. for the following loop:

```c
long f(const int *p, const int *q, long n) {
  long a = 0, b = 0;
  for (long i = 0;; i++) {
    if (p[i] && q[i]) { a += i; b += i; }
    if (i + 1 == n) break;
  }
  return a + b;
}
```

Before:


    [49 lines not shown]
DeltaFile
+24-7llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
+11-4llvm/lib/Transforms/Vectorize/LoopVectorizationPlanner.h
+5-7llvm/test/Transforms/LoopVectorize/RISCV/tail-folding-complex-mask.ll
+40-183 files

LLVM/project 27c9549llvm/test/Transforms/LoopVectorize/RISCV tail-folding-complex-mask.ll

Precommit test
DeltaFile
+163-0llvm/test/Transforms/LoopVectorize/RISCV/tail-folding-complex-mask.ll
+163-01 files

LLVM/project 348c17ellvm/test/Transforms/LoopVectorize blend-i1.ll

Precommit test
DeltaFile
+58-0llvm/test/Transforms/LoopVectorize/blend-i1.ll
+58-01 files

LLVM/project aab9d45llvm/lib/Transforms/Vectorize VPlanTransforms.cpp

[VPlan] Make simplifyRecipe more like InstCombine

Most combines in simplifyRecipe RAUW a value, but not all of them erase the old recipe.
Unify them and bring it in line with InstCombine by having it return a VPValue, which simplifyRecipes can then call RAUW with, and automatically erase the old recipe.

Similarly to InstCombine, combines that modify a recipe should return the same recipe.
DeltaFile
+1-0llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
+1-01 files

LLVM/project 741a958llvm/lib/Transforms/Vectorize VPlanTransforms.cpp, llvm/test/Transforms/LoopVectorize blend-i1.ll dont-fold-tail-for-divisible-TC.ll

[VPlan] Process simplifyRecipes in a worklist

This brings simplifyRecipes further in line with InstCombine, and asides from unlocking more simplifications it also helps avoid spurious test churn whenever passes are moved around simplifyRecipes.

For now just push the new recipe onto the worklist, not its users.
This uses a post order traversal so we maintain the same simplification order as before.

I've gone through and checked every simplification we do is a canonicalisation that converges, and I checked on llvm-test-suite + SPEC CPU 2017 in various configurations that we don't hit any cycles.
DeltaFile
+23-14llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
+4-8llvm/test/Transforms/LoopVectorize/dont-fold-tail-for-divisible-TC.ll
+2-3llvm/test/Transforms/LoopVectorize/blend-i1.ll
+29-253 files

LLVM/project 6ae4d80llvm/lib/Transforms/Vectorize VPlanTransforms.cpp, llvm/test/Transforms/LoopVectorize/VPlan constant-fold.ll

[VPlan] Make simplifyRecipe more like InstCombine

Most combines in simplifyRecipe RAUW a value, but not all of them erase the old recipe.
Unify them and bring it in line with InstCombine by having it return a VPValue, which simplifyRecipes can then call RAUW with, and automatically erase the old recipe.

Similarly to InstCombine, combines that modify a recipe should return the same recipe.
DeltaFile
+116-153llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
+6-9llvm/test/Transforms/LoopVectorize/X86/funclet.ll
+0-11llvm/test/Transforms/LoopVectorize/VPlan/constant-fold.ll
+122-1733 files

LLVM/project 1e279cellvm/lib/Transforms/Vectorize VPlanTransforms.cpp

Update trunc combine, fix m_Not return position
DeltaFile
+4-4llvm/lib/Transforms/Vectorize/VPlanTransforms.cpp
+4-41 files

LLVM/project 2437c98llvm/cmake/modules FindDIASDK.cmake

[cmake] Fix DIA SDK detection from VSINSTALLDIR (#218499)

The DIA SDK wasn't automatically detected after #160354, because
`if($Env{VSINSTALLDIR})` would be evaluated as
[`if(<string>)`](https://cmake.org/cmake/help/latest/command/if.html#string)
after expansion. This always evaluates to false unless it's one of the
true constants like `1` or `ON`. In turn the DIA SDK was never
automatically detected.

The current 23.1.0 RC builds are also built without it even though the
SDK should be available (e.g. `llvm-pdbutil diadump <pdb>` fails).

The fix is to use [`if(DEFINED
ENV{<name>})`](https://cmake.org/cmake/help/latest/command/if.html#defined).

(cherry picked from commit 5092c6ed44370d09e29ac43b346a1b430e38e1ff)
DeltaFile
+1-1llvm/cmake/modules/FindDIASDK.cmake
+1-11 files

LLVM/project ea5cc83clang/lib/Interpreter IncrementalParser.h IncrementalParser.cpp, clang/unittests/Interpreter InterpreterTest.cpp

[clang-repl] Unlink the withdrawn partial translation unit on Undo (#213235)

`Interpreter::Undo()` cleared name lookup for a withdrawn input but left its `TranslationUnitDecl` in the redeclaration chain, so walking the chain still reached declarations the user had removed. `ASTContext::TUDecl` also still pointed at the withdrawn unit, so the next input chained onto it.

`IncrementalParser::CleanUpPTU` now rebuilds the redeclaration chain without the withdrawn unit and makes its predecessor current again, the way cling's `removeRedeclFromChain` does. This needs no new AST API — `Redeclarable` and `ASTContext` already declare `friend class IncrementalParser`. The declarations stay bump-allocated in the `ASTContext`; they just stop being reachable, which is what the removed `// FIXME: We should de-allocate MostRecentTU` asked for.

`CleanUpPTU` also runs on the parse-failure path, so a failed input no longer leaves its unit in the chain either.

Fixes #213230.

---------

Co-authored-by: Emery Conrad <emery.conrad at chicagotrading.com>
(cherry picked from commit 77229133dabed0b927748f2a5ae1442b0e97f686)
DeltaFile
+48-0clang/unittests/Interpreter/InterpreterTest.cpp
+22-1clang/lib/Interpreter/IncrementalParser.cpp
+4-0clang/lib/Interpreter/IncrementalParser.h
+74-13 files

LLVM/project e9e4248llvm/lib/Target/AMDGPU AMDGPUUniformIntrinsicCombine.cpp, llvm/test/CodeGen/AMDGPU redundant-ballot-reads.ll

[AMDGPU] Combine redundant ballot intrinsic calls

Suppose there is a loop where there is a call to @llvm.amdgcn.ballot,
which maps to an instruction involving the exec mask as an operand. This
instruction duplicates if the loop is unrolled. With a higher number of
unrolled iterations, the code bloats with such redundant instructions
with $exec as there is no middle-end/backend pass which could combine
such instructions in a uniform CFG.

This patch introduces a transform in AMDGPUUniformIntrinsicCombine to
combine redundant calls to @llvm.amdgcn.ballot, to mitigate this issue.

The approach is to walk over the dominator tree and collect all calls to
@llvm.amdgcn.ballot. Map the result type and condition to the calls, to
avoid combining calls of different kinds. Calls A and B can be combined
into A iff:
- A and B are identical
- A dominates B
- all paths from A to B are uniform and exec-invariant.

    [2 lines not shown]
DeltaFile
+448-0llvm/test/CodeGen/AMDGPU/redundant-ballot-reads.ll
+170-5llvm/lib/Target/AMDGPU/AMDGPUUniformIntrinsicCombine.cpp
+618-52 files

LLVM/project 9147c9aclang/docs ReleaseNotes.md

release/23.x: [clang] Add release notes for #212122
DeltaFile
+3-0clang/docs/ReleaseNotes.md
+3-01 files

LLVM/project 831b442flang/lib/Evaluate intrinsics-library.cpp

[flang] Fix POSIX.1/XPG checks in intrinsics-library.cpp (#201072)

PR #201063 breaks the `flang` build on Solaris:

```
flang/lib/Evaluate/intrinsics-library.cpp:225:26: error: address of overloaded function 'acos' does not match required type '__float128 (__float128)'
flang/lib/Evaluate/intrinsics-library.cpp:225:26: error: address of overloaded function 'acos' does not match required type '_Complex __float128 (_Complex __float128)'

```

There are two problems here:
- The `__float128` support in `intrinsics-library.cpp` is guarded by the
POSIX.1 >= 2001/XPG >= 6 check, but only depends on `HAVE_QUADMATHLIB`.
- That check is done incorrectly: it tests for `_POSIX_C_SOURCE >=
200112L` or `_XOPEN_SOURCE >= 600`, which are no longer defined on
Solaris after the PR above. This check is due a misunderstanding of
those feature test macros: as detailed in [The Open Group Base
Specifications Issue 8, 2.2.1 POSIX.1
Symbols](https://pubs.opengroup.org/onlinepubs/9799919799/functions/V2_chap02.html),

    [17 lines not shown]
DeltaFile
+57-54flang/lib/Evaluate/intrinsics-library.cpp
+57-541 files

HardenedBSD/ports 446dfd5textproc/tgrep Makefile.crates Makefile

textproc/tgrep: Update to 1.0.2

Changelog: https://github.com/microsoft/tgrep/releases/tag/v1.0.2

Reported by:    GitHub (watch releases)
DeltaFile
+5-3textproc/tgrep/distinfo
+1-1textproc/tgrep/Makefile
+1-0textproc/tgrep/Makefile.crates
+7-43 files

FreeBSD/ports 446dfd5textproc/tgrep Makefile.crates Makefile

textproc/tgrep: Update to 1.0.2

Changelog: https://github.com/microsoft/tgrep/releases/tag/v1.0.2

Reported by:    GitHub (watch releases)
DeltaFile
+5-3textproc/tgrep/distinfo
+1-1textproc/tgrep/Makefile
+1-0textproc/tgrep/Makefile.crates
+7-43 files

HardenedBSD/ports f9566b8editors/emacs Makefile

editors/emacs: Fix native compilation with canna flavor

isearch-ext.el is a file that comes with the canna patch.  Because it is
preloaded, it was native-compiled during the bootstrap stage.  This
caused the native-lisp directory to be created, which in turn meant AOT
for all other elisp was silently skipped.

Fix this by adding isearch-ext to native-comp-bootstrap-deny-list, so it
is native-compiled later along with the rest of the elisp.

Sponsored by:   The FreeBSD Foundation
DeltaFile
+5-0editors/emacs/Makefile
+5-01 files

FreeBSD/ports f9566b8editors/emacs Makefile

editors/emacs: Fix native compilation with canna flavor

isearch-ext.el is a file that comes with the canna patch.  Because it is
preloaded, it was native-compiled during the bootstrap stage.  This
caused the native-lisp directory to be created, which in turn meant AOT
for all other elisp was silently skipped.

Fix this by adding isearch-ext to native-comp-bootstrap-deny-list, so it
is native-compiled later along with the rest of the elisp.

Sponsored by:   The FreeBSD Foundation
DeltaFile
+5-0editors/emacs/Makefile
+5-01 files

FreeBSD/ports f33b08eMk/Uses emacs.mk, editors/emacs Makefile distinfo

editors/emacs: Update to new major release, 31.1

Announcement:   https://lists.gnu.org/archive/html/info-gnu-emacs/2026-08/msg00004.html
Sponsored by:   The FreeBSD Foundation
DeltaFile
+5-5editors/emacs/distinfo
+3-3editors/emacs/Makefile
+3-3Mk/Uses/emacs.mk
+11-113 files

HardenedBSD/ports f33b08eMk/Uses emacs.mk, editors/emacs Makefile distinfo

editors/emacs: Update to new major release, 31.1

Announcement:   https://lists.gnu.org/archive/html/info-gnu-emacs/2026-08/msg00004.html
Sponsored by:   The FreeBSD Foundation
DeltaFile
+5-5editors/emacs/distinfo
+3-3editors/emacs/Makefile
+3-3Mk/Uses/emacs.mk
+11-113 files