LLVM/project 83fb72allvm/include/llvm/DWP DWP.h, llvm/lib/DWP DWP.cpp

[DWP] Eagerly clear buffers after writing (#213345)

Lowers peak memory usage on a llvm-dwp invocation from 12.37GB ->
11.19GB.

This actually now beats out GNU dwp (11.35GB) at least when the output
file is in tmpfs.
DeltaFile
+10-7llvm/lib/DWP/DWP.cpp
+8-1llvm/include/llvm/DWP/DWP.h
+18-82 files

LLVM/project 44c6aedflang/lib/Lower/OpenMP Decomposer.cpp

[flang][OpenMP] Diagnose failed construct decomposition instead of falling through (#214012)

`buildConstructQueue` asserts that decomposition produced output:

```cpp
ConstructDecomposition decompose(modOp, semaCtx, eval, compound, clauses);
assert(!decompose.output.empty() && "Construct decomposition failed");
```

Release builds have no check, so the empty queue falls through to the
loop below and out to the
caller. That is undefined behaviour, and it is reachable — semantics
does not catch every
directive/clause combination that cannot be decomposed. The result is an
intermittent segfault
rather than a diagnostic.

#211430 is one way in: `allocate` is an OpenMP 5.0 clause, but most
directives declare it in

    [45 lines not shown]
DeltaFile
+27-1flang/lib/Lower/OpenMP/Decomposer.cpp
+27-11 files

LLVM/project 8343c53utils/bazel/llvm-project-overlay/clang BUILD.bazel

[Bazel] Fixes 04722a4 (#214049)

This fixes 04722a4a32e6fec1897cc3cb5a54809fcd8c9cae (#211409).

Buildkite error link:
https://buildkite.com/llvm-project/upstream-bazel/builds?commit=04722a4a32e6fec1897cc3cb5a54809fcd8c9cae

Co-authored-by: Google Bazel Bot <google-bazel-bot at google.com>
DeltaFile
+1-0utils/bazel/llvm-project-overlay/clang/BUILD.bazel
+1-01 files

LLVM/project c740c54llvm/lib/Support/Unix Signals.inc

[SystemZ][z/OS] Add guard for SI_USER  (#213101)

SI_USER is not defined on z/OS and is causing the following build
failure. `error: use of undeclared identifier 'SI_USER'` 
This patch adds a guard to check whether SI_USER is defined
before using it.
DeltaFile
+4-1llvm/lib/Support/Unix/Signals.inc
+4-11 files

LLVM/project 0d1b546llvm/test/TableGen RegClassByHwMode.td, llvm/utils/TableGen AsmMatcherEmitter.cpp

[TableGen][AsmMatcher] Resolve RegClassByHwMode kinds for all operands

validateOperandClass() only remapped a RegClassByHwMode operand kind
when the actual parsed operand was a register. When the operand was
something else entirely (e.g. a bare immediate where a register was
expected), this fell through to the generic "Kind <= MCK_LAST_REGISTER"
diagnostic check, so we end up with a generic Match_InvalidOperand.

No test changes here, but this is needed to avoid diagnostic regressions
with the RVY load/store support (PR #177073).

Pull Request: https://github.com/llvm/llvm-project/pull/213479
DeltaFile
+5-1llvm/utils/TableGen/AsmMatcherEmitter.cpp
+1-1llvm/test/TableGen/RegClassByHwMode.td
+6-22 files

FreeBSD/ports 3264ea0www/angie distinfo, www/angie-module-njs Makefile

www/angie-module-njs: Update 0.9.9 => 1.0.0

With this milestone release, the QuickJS engine reaches feature parity
with njs and is now the recommended engine.

Changelog:
https://github.com/nginx/njs/releases/tag/1.0.0

PR:             296796
Sponsored by:   UNIS Labs

(cherry picked from commit b5584ec5fbb87e9c49c917359c3720f22a866e45)
DeltaFile
+2-2www/angie/distinfo
+1-1www/angie-module-njs/Makefile
+3-32 files

FreeBSD/ports 424666cwww/angie distinfo, www/angie-module-echo Makefile

www/angie-module-echo: Update 0.64 => 0.65

Changelog:
https://github.com/openresty/echo-nginx-module/releases/tag/v0.65

PR:             296796
Sponsored by:   UNIS Labs

(cherry picked from commit 6cd2dad7777c30fe1bf4f3e8d2df0e88d13de00d)
DeltaFile
+2-2www/angie/distinfo
+1-1www/angie-module-echo/Makefile
+3-32 files

LLVM/project dee70a0llvm/lib/Target/PowerPC/AsmParser PPCAsmParser.cpp, llvm/lib/Target/SystemZ/AsmParser SystemZAsmParser.cpp

[TableGen] Generate `getRegClassFromMatchKind()` for AsmMatchers

This helper can be useful in validateTargetOperandClass to get the
MCRegisterClass for the MCK_* enum.
Migrate the RVY logic to use this new generated function. Checking all
register classes instead of just the RVY ones will marginally slow down
validateTargetOperandClass, but since this is already a slow path it
should not matter.

If multiple RegisterOperands share a ParserMatchClass but map to different
RegisterClasses, omit them from the generated getRegClassFromMatchKind
mapping function. I originally tried to emit an error here, but it turns
out there are many targets that rely on sharing the ParserMatchClass with
different (but similar) RegisterClasses so ignoring them is safer.

Reviewed By: lenary

Pull Request: https://github.com/llvm/llvm-project/pull/200453
DeltaFile
+170-0llvm/test/TableGen/getRegClassFromMatchKind.td
+80-0llvm/utils/TableGen/AsmMatcherEmitter.cpp
+1-0llvm/lib/Target/WebAssembly/AsmParser/WebAssemblyAsmParser.cpp
+1-0llvm/lib/Target/VE/AsmParser/VEAsmParser.cpp
+1-0llvm/lib/Target/SystemZ/AsmParser/SystemZAsmParser.cpp
+1-0llvm/lib/Target/PowerPC/AsmParser/PPCAsmParser.cpp
+254-06 files not shown
+260-012 files

FreeBSD/ports 1cd0a1cwww/angie distinfo, www/angie-module-auth-jwt Makefile

www/angie-module-auth-jwt: Update 0.14.1 => 0.14.2

Changelog:
https://github.com/kjdev/nginx-auth-jwt/releases/tag/0.14.2
https://github.com/kjdev/nxe-jwx/blob/0.2.0/CHANGELOG.md

PR:             296796
Sponsored by:   UNIS Labs
Co-authored-by: Vladimir Druzenko <vvd at FreeBSD.org>

(cherry picked from commit e7fae3da5e48591a50361a5b25e40d2146ed01cd)
DeltaFile
+4-4www/angie/distinfo
+2-2www/angie-module-auth-jwt/Makefile
+6-62 files

LLVM/project cddc107llvm/lib/Target/AMDGPU AMDGPULateCodeGenPrepare.cpp, llvm/test/CodeGen/AMDGPU preload-implicit-kernargs.ll indirect-call-known-callees.ll

[AMDGPU] Do not widen constant loads that may not be dereferenceable (#184790)
DeltaFile
+83-20llvm/test/CodeGen/AMDGPU/amdgpu-late-codegenprepare.ll
+17-18llvm/lib/Target/AMDGPU/AMDGPULateCodeGenPrepare.cpp
+11-8llvm/test/CodeGen/AMDGPU/indirect-call-known-callees.ll
+6-10llvm/test/CodeGen/AMDGPU/preload-implicit-kernargs.ll
+117-564 files

LLVM/project b3ce07bllvm/include/llvm/Support PerThreadBumpPtrAllocator.h

[SystemZ][z/OS] use LLVM_THREAD_LOCAL instead of thread_local (#214039)

This patch is to fix the following error on z/OS

```
llvm/include/llvm/Support/PerThreadBumpPtrAllocator.h:75:12: error: thread-local storage is not supported for the current target
   75 |     static thread_local std::vector<AllocatorTy *> Cache;
      |            ^
```
DeltaFile
+1-1llvm/include/llvm/Support/PerThreadBumpPtrAllocator.h
+1-11 files

DragonFlyBSD/src 357c69clib/libutil pty.3, sbin/gpt gpt.8

Fix some typos in manual pages and visible text.
DeltaFile
+2-2sys/kern/vfs_lock.c
+1-1usr.bin/setcaps/setcaps.1
+1-1sbin/gpt/gpt.8
+1-1lib/libutil/pty.3
+5-54 files

LLVM/project d0bd7c1llvm/lib/Target/AMDGPU AMDGPURegBankLegalizeRules.cpp, llvm/test/CodeGen/AMDGPU llvm.amdgcn.tanh.ll

[AMDGPU][GISel] Add RegBankLegalize rules for amdgcn_tanh

Enable the existing gfx1250 and gfx13 GlobalISel coverage now that tanh operands are assigned to VGPRs.

Co-authored-by: Cursor <cursoragent at cursor.com>
DeltaFile
+570-31llvm/test/CodeGen/AMDGPU/llvm.amdgcn.tanh.ll
+1-1llvm/lib/Target/AMDGPU/AMDGPURegBankLegalizeRules.cpp
+571-322 files

LLVM/project a967e37llvm/lib/Target/AMDGPU AMDGPULegalizerInfo.cpp, llvm/test/CodeGen/AMDGPU/GlobalISel legalize-fneg.mir legalize-fabs.mir

[AMDGPU][GlobalISel] Legalize BF16 fneg and fabs

Restore the BF16 semantic types omitted by the extended LLT migration and preserve packed vector legalization.

Co-authored-by: Cursor <cursoragent at cursor.com>
DeltaFile
+112-0llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-fneg.mir
+112-0llvm/test/CodeGen/AMDGPU/GlobalISel/legalize-fabs.mir
+3-1llvm/lib/Target/AMDGPU/AMDGPULegalizerInfo.cpp
+227-13 files

LLVM/project 04722a4clang/include/clang/DependencyScanning DependencyScanningWorker.h DependencyScannerImpl.h, clang/lib/DependencyScanning CMakeLists.txt DependencyScannerImpl.cpp

[clang][DependencyScanning] Dissolve DependencyScannerImpl.h/cpp (#211409)

`DependencyScannerImpl.h/cpp` were created to share code between TU
scanning and by-name scanning when they were on different code paths.
After unifying the implementation through `CompilerInstanceWithContext`,
we no longer need a separate header/cpp pair and all the code are moved
into `DependencyScanningWorker.cpp`. This PR is mechnical and does not
intend to introduce behavivor changes.

---

<sub>Stack created with <a
href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a
href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
DeltaFile
+511-26clang/lib/DependencyScanning/DependencyScanningWorker.cpp
+0-525clang/lib/DependencyScanning/DependencyScannerImpl.cpp
+0-89clang/include/clang/DependencyScanning/DependencyScannerImpl.h
+14-9clang/lib/Tooling/DependencyScanningTool.cpp
+5-2clang/include/clang/DependencyScanning/DependencyScanningWorker.h
+0-1clang/lib/DependencyScanning/CMakeLists.txt
+530-6523 files not shown
+531-6549 files

LLVM/project 7f498d9clang/include/clang/DependencyScanning DependencyScannerImpl.h, clang/lib/DependencyScanning DependencyScannerImpl.cpp DependencyScanningWorker.cpp

[clang][DependencyScanning] Use CompilerInstanceWithContext for TU Scanning (#211408)

After `CompilerInstanceWithContext`'s relocation to
`DependencyScanningWorker.cpp`, we can use it freely as an
implementation engine for TU scanning. This PR does that, and unifies
the by-name scanning and TU scanning so they all go through
`CompilerInstanceWithContext`.

rdar://167034309



---

<sub>Stack created with <a
href="https://github.com/github/gh-stack">GitHub Stacks CLI</a> • <a
href="https://gh.io/stacks-feedback">Give Feedback 💬</a></sub>
DeltaFile
+315-38clang/lib/DependencyScanning/DependencyScanningWorker.cpp
+0-293clang/lib/DependencyScanning/DependencyScannerImpl.cpp
+35-0clang/unittests/Tooling/DependencyScannerTest.cpp
+0-27clang/include/clang/DependencyScanning/DependencyScannerImpl.h
+1-0clang/test/ClangScanDeps/logging-simple.c
+351-3585 files

LLVM/project 1752f08llvm/test/tools/llvm-objcopy/ELF binary-output-target.test

[llvm-objcopy] Add AMDGPU case to binary-output-target.test

Add test coverage for converting binary input to elf64-amdgpu format,
verifying the output has the correct format string, arch (amdgpu),
and machine type (EM_AMDGPU 0xE0). Follows the same pattern as all
other architectures in this test file.
DeltaFile
+6-0llvm/test/tools/llvm-objcopy/ELF/binary-output-target.test
+6-01 files

LLVM/project 569d63cllvm/test/tools/llvm-objcopy/ELF cross-arch-headers.test

[llvm-objcopy] Fix AMDGPU arch string in test: amdgpu not amdgcn

llvm-readobj reports 'Arch: amdgpu' for EM_AMDGPU ELF files
(the generic AMDGPU ELF format used by elf64-amdgpu). The test
was incorrectly expecting 'amdgcn', which is the AMDGCN-specific
arch string used by ROCm HSA code objects.
DeltaFile
+1-1llvm/test/tools/llvm-objcopy/ELF/cross-arch-headers.test
+1-11 files

LLVM/project 5060c2dllvm/test/tools/llvm-objcopy/ELF binary-output-target.test cross-arch-headers.test

[llvm-objcopy] Address reviewer feedback on AMDGPU test cleanups

- Remove unused -DMACHINE yaml2obj template variable in cross-arch-headers.test,
  hardcode Machine: EM_NONE directly in the YAML instead
- Remove unused Flags: [[FLAGS=<none>]] template variable in cross-arch-headers.test
- Add comment in binary-output-target.test explaining that Arch: unknown is
  intentional when converting from binary (e_flags=0, no EF_AMDGPU_MACH set)
DeltaFile
+2-3llvm/test/tools/llvm-objcopy/ELF/cross-arch-headers.test
+2-0llvm/test/tools/llvm-objcopy/ELF/binary-output-target.test
+4-32 files

LLVM/project 6141f1bllvm/test/tools/llvm-objcopy/ELF cross-arch-headers.test, llvm/tools/llvm-objcopy ObjcopyOptions.cpp

[AMDGPU] Add AMDGPU support for llvm-objcopy

Co-authored-by: Aakanksha Patil <paakan at amd.com>
DeltaFile
+11-2llvm/test/tools/llvm-objcopy/ELF/cross-arch-headers.test
+2-0llvm/tools/llvm-objcopy/ObjcopyOptions.cpp
+13-22 files

LLVM/project c149a5dllvm/test/tools/llvm-objcopy/ELF cross-arch-headers.test

[llvm-objcopy] Address review feedback for AMDGPU test in cross-arch-headers

Per reviewer feedback, use the existing non-AMDGPU input (%t.o, EM_NONE)
to test conversion to elf64-amdgpu. This properly demonstrates that
--output-format changes the machine type, consistent with all other cases
in this test file.

The output reports Arch: unknown because converting from a non-AMDGPU ELF
produces e_flags=0 (no EF_AMDGPU_MACH set); added a comment explaining
this. Flag control is a separate concern for a follow-on PR.
DeltaFile
+5-3llvm/test/tools/llvm-objcopy/ELF/cross-arch-headers.test
+5-31 files

LLVM/project b380f0allvm/test/tools/llvm-objcopy/ELF binary-output-target.test

[llvm-objcopy] Fix AMDGPU arch checks in tests

ELFObjectFile.h getArch() for EM_AMDGPU returns Triple::UnknownArch
when e_flags & EF_AMDGPU_MACH is 0 (no GPU target specified). Only
when a MACH flag in the AMDGCN range is present does it return
Triple::amdgpu.

- cross-arch-headers.test: restore EF_AMDGPU_MACH_AMDGCN_GFX900 flag
  on the input ELF so that after format conversion the output correctly
  reports Arch: amdgpu.

- binary-output-target.test: expect Arch: unknown since converting
  from raw binary input (-I binary) produces an ELF with e_flags=0
  (no MACH flags), giving UnknownArch. This is correct behavior.
DeltaFile
+1-1llvm/test/tools/llvm-objcopy/ELF/binary-output-target.test
+1-11 files

FreeBSD/ports 3830c47math/alberta/files patch-Makefile.ams

math/alberta: Fix building with libtool 2.6

PR:             296964
Approved by:    portmgr (fixit blanket)
DeltaFile
+66-0math/alberta/files/patch-Makefile.ams
+66-01 files

FreeBSD/ports 0291844biology/iolib Makefile

biology/iolib: Fix building with libtool 2.6

PR:             296964
Approved by:    portmgr (fixit blanket)
DeltaFile
+3-0biology/iolib/Makefile
+3-01 files

LLVM/project d46ded5llvm/lib/Target/AMDGPU AMDGPURegBankLegalizeRules.cpp, llvm/test/CodeGen/AMDGPU llvm.amdgcn.cvt.scalef32.sr.pk.gfx950.ll llvm.amdgcn.cvt.scalef32.pk.gfx950.ll

Add tests, fix some rules
DeltaFile
+84-0llvm/test/CodeGen/AMDGPU/llvm.amdgcn.cvt.scalef32.sr.ll
+70-0llvm/test/CodeGen/AMDGPU/llvm.amdgcn.cvt.scale.pk.ll
+69-0llvm/test/CodeGen/AMDGPU/llvm.amdgcn.cvt.scalef32.pk.gfx950.ll
+14-0llvm/test/CodeGen/AMDGPU/llvm.amdgcn.cvt.scalef32.sr.pk.gfx950.ll
+6-2llvm/lib/Target/AMDGPU/AMDGPURegBankLegalizeRules.cpp
+243-25 files

FreeBSD/doc 90eb071documentation/content/en/articles/pgpkeys _index.adoc, documentation/static/pgpkeys adrian.key

pgpkeys: add adrian@ pgp key

I finally found it; add both keys

Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D58645
DeltaFile
+90-0documentation/static/pgpkeys/adrian.key
+3-0documentation/content/en/articles/pgpkeys/_index.adoc
+93-02 files

FreeBSD/ports b41f0b3x11-drivers/xlibre-xf86-video-amdgpu Makefile distinfo

x11-drivers/xlibre-xf86-video-amdgpu: Update to 25.1.2

(cherry picked from commit 902f3a4296a215fe01866a4bf520c375682e097e)
DeltaFile
+3-3x11-drivers/xlibre-xf86-video-amdgpu/distinfo
+1-2x11-drivers/xlibre-xf86-video-amdgpu/Makefile
+4-52 files

FreeBSD/ports 8ba145bx11-servers/xlibre-server pkg-plist Makefile.version

x11-servers/xlibre-server: Update to 25.1.9

ChangeLog at:   https://github.com/X11Libre/xserver/releases/tag/xlibre-xserver-25.1.9
With hat:       xlibre

(cherry picked from commit f130c3d1e979ec814d40fcb5609bef0a1f3c88a0)
DeltaFile
+3-3x11-servers/xlibre-server/distinfo
+0-2x11-servers/xlibre-server/pkg-plist
+1-1x11-servers/xlibre-server/Makefile.version
+1-1x11-servers/xlibre-server/Makefile
+5-74 files

OpenZFS/src 674b1aeinclude/sys zap.h, module/zfs ddt_zap.c zap.c

DDT: Make ddt_zap_walk() use cursor _by_dnode functions

ddt_zap_walk() already receives dnode as an argument.  We can save
one dnode_hold() per entry by using _by_dnode cursor functions.
zap_cursor_init_noprefetch_by_dnode() is added in the process.

Signed-off-by: Alexander Motin <alexander.motin at TrueNAS.com>
Reviewed-by: Rob Norris <rob.norris at truenas.com>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Closes #18888
DeltaFile
+6-0module/zfs/zap.c
+2-3module/zfs/ddt_zap.c
+1-0include/sys/zap.h
+9-33 files

LLVM/project c529663llvm/test/Transforms/LoopVectorize/VPlan vplan-based-stride-mv.ll

[NFC][VPlan] Add scalable vectors RUN-line to vplan-based-stride-mv.ll
DeltaFile
+284-0llvm/test/Transforms/LoopVectorize/VPlan/vplan-based-stride-mv.ll
+284-01 files