LLVM/project cc0913eclang/lib/AST/ByteCode Compiler.cpp, clang/test/AST/ByteCode records.cpp

[clang][bytecode] Fix `MemberExpr`s with a static member (#193902)

We need logic to load from the reference pointer, similar to the one we
have for regular `DeclRefExpr`s.
DeltaFile
+19-14clang/lib/AST/ByteCode/Compiler.cpp
+31-0clang/test/AST/ByteCode/libcxx/static-reference-load.cpp
+16-1clang/test/AST/ByteCode/records.cpp
+66-153 files

LLVM/project 9df51a9mlir/include/mlir/Dialect/LLVMIR NVVMOps.td, mlir/lib/Dialect/LLVMIR/IR NVVMDialect.cpp

[MLIR][NVVM] Add `nvvm.sin` OP (#193775)

Implement `nvvm.sin` with ftz flag
DeltaFile
+25-0mlir/include/mlir/Dialect/LLVMIR/NVVMOps.td
+15-0mlir/test/Dialect/LLVMIR/nvvm-transcendentals.mlir
+15-0mlir/test/Target/LLVMIR/nvvm/transcendentals.mlir
+10-0mlir/lib/Dialect/LLVMIR/IR/NVVMDialect.cpp
+65-04 files

LLVM/project 23ea736llvm/lib/Analysis AliasAnalysisEvaluator.cpp, llvm/test/Analysis/BasicAA atomics.ll

[AAEval] Print ModRefInfo for atomic operations (#193935)

Print ModRefInfo for fence, atomicrmw, etc. Also for atomic
load and store, as these may have additional effects beyond
what is implied by the simple alias result.
DeltaFile
+181-0llvm/test/Analysis/BasicAA/atomics.ll
+26-23llvm/lib/Analysis/AliasAnalysisEvaluator.cpp
+207-232 files

LLVM/project 6771384llvm/docs LangRef.rst

[LangRef] Specify that syncscopes can affect the monotonic modification order

If a target specifies that atomics with mismatching syncscopes appear
non-atomic to each other, there is no point in requiring them to be ordered in
the monotonic modification order. Notably, the [AMDGPU target user
guide](https://llvm.org/docs/AMDGPUUsage.html#memory-scopes) has specified
syncscopes to relax the modification order for years.

So far, I haven't found an example where this less constrained ordering would
be observable (at least with the AMDGPU inclusive scope rules). Whenever a load
would be able to see two monotonic stores with non-inclusive scope, that's
considered a data race (i.e., the load would return `undef`), so it cannot be
used to observe the order of the stores.
DeltaFile
+13-9llvm/docs/LangRef.rst
+13-91 files

LLVM/project 390a29elldb/include/lldb/Target MemoryRegionInfo.h, lldb/source/Target MemoryRegionInfo.cpp

Revert "[lldb][Linux] Read memory protection keys for memory regions" (#193934)

Reverts llvm/llvm-project#182246

Test failures on x86 bot:
```
Failed Tests (2):
  lldb-api :: tools/lldb-server/TestGdbRemote_qMemoryRegion.py
  lldb-api :: tools/lldb-server/libraries-svr4/TestGdbRemoteLibrariesSvr4Support.py
```
DeltaFile
+0-40lldb/unittests/Process/Utility/LinuxProcMapsTest.cpp
+0-20lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
+0-17lldb/test/API/linux/aarch64/permission_overlay/TestAArch64LinuxPOE.py
+8-8lldb/source/Target/MemoryRegionInfo.cpp
+1-10lldb/include/lldb/Target/MemoryRegionInfo.h
+0-5lldb/test/API/linux/aarch64/permission_overlay/main.c
+9-1005 files not shown
+9-11511 files

LLVM/project d60a0e2llvm/docs AMDGPUUsage.rst

[AMDGPUUsage] Specify what one-as syncscopes do

This matches the currently implemented and (as far as I could determine)
intended semantics of these syncscopes.
The sync scope table is unchanged except for removing its indentation;
otherwise it would be rendered as part of the preceding note.
DeltaFile
+89-77llvm/docs/AMDGPUUsage.rst
+89-771 files

LLVM/project ee4f9e0llvm/docs AMDGPUUsage.rst LangRef.rst

[LangRef][AMDGPU] Specify that syncscope can cause atomic operations to race

Targets should be able to specify that the syncscope of atomic operations
influences whether they participate in data races with each other.

For example, in AMDGPU, we want (and already implement) the load in the
following case to be in a data race (i.e., return `undef` according to the
current definition), because there is an atomic store with workgroup syncscope
executing in a different workgroup:

```
; workgroup 0:
  store atomic i32 1, ptr %p syncscope("workgroup") monotonic, align 4

; workgroup 1:
  store atomic i32 2, ptr %p syncscope("workgroup") monotonic, align 4
  load atomic i32, ptr %p syncscope("workgroup") monotonic, align 4
```


    [3 lines not shown]
DeltaFile
+4-1llvm/docs/AMDGPUUsage.rst
+2-1llvm/docs/LangRef.rst
+6-22 files

LLVM/project e2159f8llvm/docs LangRef.rst

[LangRef] Allow monotonic & seq_cst accesses to inter-operate with other accesses (#189014)

Currently, the LangRef says that atomic operations (which includes `unordered`
operations, which don't participate in the monotonic modification order) must
read a value from the modification order of monotonic operations.

In the following example, this means that the load does not have a store it
could read from, because all stores it may see do not participate in the
monotonic modification order:

```
; thread 0:
  store atomic i32 1, ptr %p unordered, align 4

; thread 1:
  store atomic i32 2, ptr %p unordered, align 4
  load atomic i32, ptr %p unordered, align 4
```


    [19 lines not shown]
DeltaFile
+12-10llvm/docs/LangRef.rst
+12-101 files

NetBSD/pkgsrc Pwcm87pdoc CHANGES-2026

   Updated www/py-scrapy, converters/py-simplejson
VersionDeltaFile
1.2556+3-1doc/CHANGES-2026
+3-11 files

NetBSD/pkgsrc pzcf4ZPconverters/py-simplejson distinfo Makefile

   py-simplejson: updated to 4.1.0

   Version 4.1.0 released 2026-04-22

   * The C extension now accelerates encoding when ``indent=`` is set.
     Previously the encoder fell back to the pure-Python implementation
     whenever a non-None ``indent`` was passed; now the C encoder emits
     the newline-plus-indent prefix, the level-aware item separator, and
     the closing indent directly.  A representative nested-dict workload
     benchmarks about 4-5x faster end-to-end, and the ``indent=0`` and
     empty-container edge cases continue to match the Python output
     byte-for-byte.

   * The C extension now emits PEP 678 ``exc.add_note()`` annotations on
     serialization failures, matching the pure-Python encoder.  A chained
     error on ``{'a': [1, object(), 3]}`` produces the same three notes
     (``when serializing object object``, ``when serializing list item 1``,
     ``when serializing dict item 'a'``) whether the speedups are loaded
     or not, so the add_note assertions in ``test_errors.py`` no longer
     need ``indent=2`` to force the Python path.
VersionDeltaFile
1.46+4-4converters/py-simplejson/distinfo
1.59+2-2converters/py-simplejson/Makefile
+6-62 files

NetBSD/pkgsrc 9BwsuoGwww/py-scrapy distinfo Makefile

   py-scrapy: updated to 2.15.1

   Scrapy 2.15.1 (2026-04-23)

   Bug fixes

   - Sharing of the SSL context between multiple connections, introduced in
     Scrapy 2.15.0, is reverted as it caused problems and wasn't actually
     needed.

   - Fixed :meth:`scrapy.settings.BaseSettings.getwithbase` failing on keys with
     dots that aren't import names. It now works the way it worked before Scrapy
     2.15.0, without trying to match class objects and import path. A separate
     method,
     :func:`~scrapy.settings.BaseSettings.get_component_priority_dict_with_base`,
     was added that does that, and it is now used for :ref:`component priority
     dictionaries <component-priority-dictionaries>`.

   - Documentation rendering improvements.
VersionDeltaFile
1.28+4-4www/py-scrapy/distinfo
1.38+2-2www/py-scrapy/Makefile
+6-62 files

LLVM/project 69724c8lldb/include/lldb/Target MemoryRegionInfo.h, lldb/source/Target MemoryRegionInfo.cpp

[lldb][Linux] Read memory protection keys for memory regions (#182246)

Memory protection keys
(https://docs.kernel.org/core-api/protection-keys.html) are implemented
using two things:
* A key value attached to each page table entry.
* A set of permissions stored somewhere else (in a register on AArch64
and X86), which is indexed into by that protection key.

So far I have updated LLDB to show the permissions part on AArch64 Linux
by reading the por register. Now I am adding the ability to see which
key each memory region is using.

```
(lldb) memory region --all
[0x0000000000000000-0x000aaaae3b140000) ---
[0x000aaaae3b140000-0x000aaaae3b150000) r-x /tmp/test_lldb/linux/aarch64/permission_overlay/2/TestAArch64LinuxPOE/a.out PT_LOAD[0]
protection key: 0
[0x000aaaae3b150000-0x000aaaae3b160000) rw- /tmp/test_lldb/linux/aarch64/permission_overlay/2/TestAArch64LinuxPOE/a.out

    [27 lines not shown]
DeltaFile
+40-0lldb/unittests/Process/Utility/LinuxProcMapsTest.cpp
+20-0lldb/unittests/Process/gdb-remote/GDBRemoteCommunicationClientTest.cpp
+17-0lldb/test/API/linux/aarch64/permission_overlay/TestAArch64LinuxPOE.py
+8-8lldb/source/Target/MemoryRegionInfo.cpp
+10-1lldb/include/lldb/Target/MemoryRegionInfo.h
+5-0lldb/test/API/linux/aarch64/permission_overlay/main.c
+100-95 files not shown
+115-911 files

NetBSD/pkgsrc tbcGQjcdoc CHANGES-2026

   Updated devel/py-filelock, devel/py-faker
VersionDeltaFile
1.2555+3-1doc/CHANGES-2026
+3-11 files

NetBSD/pkgsrc KUTwlpIdevel/py-faker PLIST distinfo

   py-faker: updated to 40.15.0

   40.15.0 - 2026-04-17

   * Add job providers for `ar_DZ` and `fr_DZ` locales
   * Add company providers for `ar_DZ` and `fr_DZ` locales
   * Add geo providers for `ar_DZ` and `fr_DZ` locales
   * Add currency providers for `ar_DZ` and `fr_DZ` locales
   * Add `date_time` provider for `ar_DZ` locale
   * Add ssn providers for `ar_DZ` and `fr_DZ` locales
VersionDeltaFile
1.71+34-1devel/py-faker/PLIST
1.111+4-4devel/py-faker/distinfo
1.117+2-2devel/py-faker/Makefile
+40-73 files

NetBSD/pkgsrc 2Gaxpwrdevel/py-filelock distinfo Makefile

   py-filelock: updated to 3.29.0

   3.29.0

   fix(async): use single-thread executor for lock consistency
   feat(soft): enable stale lock detection on Windows
VersionDeltaFile
1.44+4-4devel/py-filelock/distinfo
1.45+2-2devel/py-filelock/Makefile
+6-62 files

NetBSD/pkgsrc Wc4sEvCdoc CHANGES-2026

   Updated security/opensc, devel/py-greenlet
VersionDeltaFile
1.2554+3-1doc/CHANGES-2026
+3-11 files

NetBSD/pkgsrc Q5Wct6Zdevel/py-virtualenv Makefile

   py-virtualenv: use PY_RENAME_BINARIES
VersionDeltaFile
1.108+4-6devel/py-virtualenv/Makefile
+4-61 files

NetBSD/pkgsrc ya1hjgMdevel/py-greenlet distinfo Makefile

   py-greenlet: updated to 3.4.0

   3.4.0 (2026-04-08)

   - Publish binary wheels for RiscV 64.
   - Fix multiple rare crash paths during interpreter shutdown.

     Note that this now relies on the ``atexit`` module, and introduces
     subtle API changes during interpreter shutdown (for example,
     ``getcurrent`` is no longer available once the ``atexit`` callback fires).

   - Address the results of an automated code audit performed by
     Daniel Diniz. This includes several minor correctness changes that
     theoretically could have been crashing bugs, but typically only in
     very rare circumstances.

   - Fix several race conditions that could arise in free-threaded
     builds when using greenlet objects from multiple threads, some of
     which could lead to assertion failures or interpreter crashes.
VersionDeltaFile
1.37+4-4devel/py-greenlet/distinfo
1.39+2-2devel/py-greenlet/Makefile
+6-62 files

FreeBSD/ports 6261726x11-wm/mango distinfo Makefile

x11-wm/mango: Update to 0.12.9

ChangeLog:      https://github.com/mangowm/mango/releases/tag/0.12.9
Reported by:    DreamMaoMao <notifications at github.com>
DeltaFile
+3-3x11-wm/mango/distinfo
+1-1x11-wm/mango/Makefile
+4-42 files

NetBSD/pkgsrc DLRTOjBsecurity/opensc distinfo Makefile

   opensc: updated to 0.27.1

   New in 0.27.1; 2026-03-31

   * Bugfix release to fix up infrastructure issues.

   New in 0.27.0; 2026-03-30

   Security
   * CVE-2025-13763: Several uses of potentially uninitialized memory detected by fuzzers
   * CVE-2025-49010: Possible write beyond buffer bounds during processing of GET RESPONSE APDU
   * CVE-2025-66215: Possible write beyond buffer bounds in oberthur driver
   * CVE-2025-66038: Possible read beyond buffer bounds when parsing historical bytes in PIV driver
   * CVE-2025-66037: Possible buffer overrun while parsing SPKI
   * More low-severity data handling issues when parsing profile configuration

   General improvements
   * Added support for PKCS#11 3.2 in tools and pkcs11-spy and p11test
   * Added support for Ed448, X448 mechanisms and improve support for

    [52 lines not shown]
VersionDeltaFile
1.27+4-4security/opensc/distinfo
1.57+2-3security/opensc/Makefile
+6-72 files

LLVM/project faf37adclang/utils/TableGen ClangOptionDocEmitter.cpp

[Clang] Use const std::string & in ClangOptionDocEmitter. NFC. (#193926)

Fixes #94373
DeltaFile
+1-1clang/utils/TableGen/ClangOptionDocEmitter.cpp
+1-11 files

FreeBSD/ports 8b32d76lang/gnat14 pkg-plist

lang/gnat14: fix plist on aarch64
DeltaFile
+1-1lang/gnat14/pkg-plist
+1-11 files

NetBSD/pkgsrc EsYndAHdoc CHANGES-2026

   doc: Updated devel/nss to 3.123.1
VersionDeltaFile
1.2553+2-1doc/CHANGES-2026
+2-11 files

NetBSD/pkgsrc XncHYhzdevel/nss distinfo Makefile

   nss: update to 3.123.1.

   Changes:

       Bug 2033783 - reject DTLS 1.3 Server Hello after HVR without capping ss->vrange.max.
VersionDeltaFile
1.210+4-4devel/nss/distinfo
1.295+2-2devel/nss/Makefile
+6-62 files

NetBSD/pkgsrc ZPDBIRGdoc CHANGES-2026

   Updated devel/py-virtualenv, devel/py-tox
VersionDeltaFile
1.2552+3-1doc/CHANGES-2026
+3-11 files

NetBSD/pkgsrc AQYFrIUdevel/py-tox Makefile PLIST

   py-tox: updated to 4.53.0

   Features - 4.53.0

   TOML env_list now accepts bare range dicts ({ prefix = "3.", start = 12, stop = 14 }) and bare labeled dicts ({ ecosystem = ["oci", "python"] }) as top-level items, removing the { product = [...] } wrapper when there is only a single factor group

   Bug fixes - 4.53.0

   Nesting a range or labeled dict inside a product factor-group list now raises a clear error pointing at the un-nesting fix, instead of silently producing a malformed environment name
VersionDeltaFile
1.66+10-4devel/py-tox/Makefile
1.17+8-1devel/py-tox/PLIST
1.55+4-4devel/py-tox/distinfo
+22-93 files

NetBSD/pkgsrc DmmYIIYdevel/py-virtualenv distinfo Makefile

   py-virtualenv: updated to 21.2.4

   Bugfixes - 21.2.4
   Security hardening: validate each entry of a seed wheel archive before extracting it so a tampered wheel cannot escape the app-data image directory via an absolute path or .. traversal.
   Security hardening: verify the SHA-256 of every bundled seed wheel when it is loaded so a corrupted or tampered file on disk fails loud instead of being handed to pip. The hash table is generated alongside BUNDLE_SUPPORT by tasks/upgrade_wheels.py.
   Security hardening: validate the distribution name and version specifier passed to pip download when acquiring a seed wheel so extras, pip flags, or shell metacharacters cannot be smuggled into the subprocess command line.
   Security hardening: replace the string-prefix containment check in virtualenv.util.zipapp with Path.relative_to so the zipapp extraction helpers refuse any path that does not resolve under the archive root.
   Security hardening: do not silently fall back to an unverified HTTPS context when the periodic update request to PyPI fails TLS verification. The returned metadata drives which wheel version virtualenv considers “up to date”, so accepting an unverified response lets a network-level attacker suppress security updates. Set VIRTUALENV_PERIODIC_UPDATE_INSECURE=1 to restore the previous behavior on hosts with broken trust stores.
VersionDeltaFile
1.91+4-4devel/py-virtualenv/distinfo
1.107+3-3devel/py-virtualenv/Makefile
1.80+2-2devel/py-virtualenv/PLIST
+9-93 files

FreeBSD/ports b7eef55editors/zed distinfo Makefile.crates, editors/zed/files patch-crates_fs_src_fs.rs patch-Cargo.lock

editors/zed: Update to 0.233.7

Changelog:
- https://github.com/zed-industries/zed/releases/tag/v0.232.3
- https://github.com/zed-industries/zed/releases/tag/v0.233.5
- https://github.com/zed-industries/zed/releases/tag/v0.233.6
- https://github.com/zed-industries/zed/releases/tag/v0.233.7

Reported by:    GitHub (watch releases)
DeltaFile
+19-23editors/zed/distinfo
+9-9editors/zed/files/patch-crates_fs_src_fs.rs
+8-10editors/zed/Makefile.crates
+8-8editors/zed/files/patch-Cargo.lock
+5-5editors/zed/files/patch-crates_zed_src_main.rs
+3-3editors/zed/files/patch-crates_project_src_agent__server__store.rs
+52-585 files not shown
+62-6811 files

FreeBSD/ports 9170407www/gitlab-workhorse Makefile

www/gitlab-workhorse: mark i386 as broken, not supported upstream

(cherry picked from commit 633dd39274940346f61d311175b389885521d2ac)
DeltaFile
+2-0www/gitlab-workhorse/Makefile
+2-01 files

FreeBSD/ports a7dd8bcdevel/gitaly distinfo, net/gitlab-agent distinfo

www/gitlab: security and patch update to 18.11.1

Changes:        https://docs.gitlab.com/releases/patches/patch-release-gitlab-18-11-1-released/
Security:       73b927a6-3ecd-11f1-be20-2cf05da270f3
(cherry picked from commit 4f0eaf1f35f3f2f925c35ce5611e85d48a49ebe2)
DeltaFile
+11-11devel/gitaly/distinfo
+6-6www/gitlab/distinfo
+5-5net/gitlab-agent/distinfo
+5-5www/gitlab-pages/distinfo
+5-5www/gitlab-workhorse/distinfo
+4-4www/gitlab/Makefile
+36-361 files not shown
+37-377 files