FreeBSD/ports 2134476graphics/librsvg2-rust distinfo Makefile

graphics/librsvg2-rust: Update to 2.62.3
DeltaFile
+3-3graphics/librsvg2-rust/distinfo
+1-2graphics/librsvg2-rust/Makefile
+1-1graphics/librsvg2-rust/pkg-plist
+5-63 files

LLVM/project add2d9allvm/test/tools/llvm-pdbutil dxcontainer.test, llvm/tools/llvm-pdbutil DumpOutputStyle.cpp StreamUtil.cpp

[llvm-pdbutil] Add DXContainer support to `llvm-pdbutil dump` (#200485)

This patch adds `--dxcontainer` option that attempts to parse a
`DXContainer` from stream 5 data (generated by DirectX tools) of a PDB
file, and if successful, dumps the basic info about it. If `DXContainer`
wasn't parsed, shows that it is not present in the file.
DeltaFile
+42-0llvm/tools/llvm-pdbutil/DumpOutputStyle.cpp
+25-0llvm/test/tools/llvm-pdbutil/dxcontainer.test
+6-0llvm/tools/llvm-pdbutil/StreamUtil.cpp
+3-0llvm/tools/llvm-pdbutil/llvm-pdbutil.cpp
+1-0llvm/tools/llvm-pdbutil/llvm-pdbutil.h
+1-0llvm/tools/llvm-pdbutil/DumpOutputStyle.h
+78-01 files not shown
+79-07 files

LLVM/project f1bdb76mlir/include/mlir/Dialect/MemRef/IR MemRefOps.td, mlir/lib/Conversion/MemRefToLLVM MemRefToLLVM.cpp

[mlir][MemRefToLLVM] fix incorrect `nuw` on `GEP/mul` when lowering `memref.load/store` with negative strides (#204309)

`MemRefToLLVM` was unconditionally emitting `getelementptr inbounds|nuw`
(and consequently `mul overflow<nsw,nuw>` on every intermediate index
computation inside `getStridedElementPtr`) for all `memref.load` and
`memref.store` lowerings.

This is _unsound_ when any stride is negative or dynamic.
`getStridedElementPtr` propagates `GEPNoWrapFlags::nuw` to
`IntegerOverflowFlags::nuw` on every intermediate `llvm.mul` and
`llvm.add` it emits. With a negative stride (e.g. `-1`, which is
`2^64-1` unsigned), an access like index=5 produces `mul nuw 5,
(2^64-1)`, which unsigned-overflows and yields poison per LangRef —
regardless of whether the final offset happens to be non-negative.

This issue came up in the discussion in PR #202118. Thanks to
@banach-space for the detailed discussion.

This PR hopefully concludes the path to fix the regression related to

    [6 lines not shown]
DeltaFile
+30-12mlir/test/Conversion/MemRefToLLVM/convert-dynamic-memref-ops.mlir
+20-8mlir/lib/Conversion/MemRefToLLVM/MemRefToLLVM.cpp
+16-8mlir/include/mlir/Dialect/MemRef/IR/MemRefOps.td
+1-1mlir/test/Conversion/MemRefToLLVM/expand-then-convert-to-llvm.mlir
+67-294 files

LLVM/project 8e181f4clang/test/Driver amdgpu-xnack-sramecc-flags.c, llvm/lib/Target/AMDGPU AMDGPUAsmPrinter.cpp

AMDGPU: Use module flags to control xnack and sramecc

This ensures these ABI details are encoded in the IR module
rather than depending on external state from command-line flags.
Previously, these were encoded as function-level subtarget features.
The code object output was a single target ID directive implied
by the global subtarget. The backend would previously check if a
function's subtarget feature mismatched the global subtarget. This
is avoided by making xnack and sramecc module-level properties from
the start. This also provides proper linker compatibility
enforcement, moving the error point earlier.

The old encoding was also an abuse of the subtarget feature system.
Subtarget features are a bitvector, and later features in the string
can override earlier ones. The old handling added a special case
where explicit settings were preserved: ordinarily +feature,-feature
should result in the feature being disabled, but +xnack,-xnack would
preserve the explicit "-xnack" state, which differs from the absence
of any xnack setting.

    [25 lines not shown]
DeltaFile
+52-52llvm/test/CodeGen/AMDGPU/directive-amdgcn-target.ll
+30-46llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.cpp
+75-0llvm/test/CodeGen/AMDGPU/module-flag-xnack.ll
+36-33clang/test/Driver/amdgpu-xnack-sramecc-flags.c
+66-0llvm/test/CodeGen/AMDGPU/module-flag-sramecc.ll
+47-4llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp
+306-13592 files not shown
+1,105-35498 files

LLVM/project d2dd4ceclang/lib/AST/ByteCode EvaluationResult.h

[clang][bytecode][NFC] Mark results as non-empty when taking a value (#204568)

This was missing and all the EvaluationResults always ended up being
empty even though their APValue was set. Since the assert(!empty()) was
missing from `takeAPValue()`, nobody noticed though.
DeltaFile
+3-7clang/lib/AST/ByteCode/EvaluationResult.h
+3-71 files

FreeNAS/freenas f70131e. CLAUDE.md, src/middlewared/middlewared/plugins auth.py

NAS-141435 / 27.0.0-BETA.1 / Fix public API method docstrings (RST, doc references, JSON-RPC examples) (#19157)

## Summary

Fix docutils errors and poor RST rendering on several API docs pages,
and document conventions for public method docstrings in CLAUDE.md.

This PR does NOT represent a sweep of every public method docstring for
formatting improvements. Its primary aim is to fix all docutils errors,
format JSON embedded in descriptions, and fix other improper RST
formatting. Other improvements like RST admonitions are limited in scope
to these methods.

## Motivation

Public method docstrings are rendered into the API reference
documentation. They need to be written with the generated docs and
general API consumers in mind rather than developer comfort. We should
move away from mixing styles: Google/NumPy-style

    [47 lines not shown]
DeltaFile
+208-189src/middlewared/middlewared/plugins/zfs/snapshot_crud.py
+41-97src/middlewared/middlewared/plugins/auth.py
+61-61src/middlewared/middlewared/plugins/webui/enclosure.py
+61-58src/middlewared/middlewared/plugins/nfs_/status.py
+60-54src/middlewared/middlewared/plugins/zfs/resource_crud.py
+22-79CLAUDE.md
+453-53820 files not shown
+765-66026 files

FreeBSD/ports 5fe0289databases/mongodb70 distinfo Makefile

databases/mongodb70: re-enable python3.12

The patch was disabled temporarily because it was in the way of the recent upgrades.
NB: a test build was already running when this PR came in.

- Remove jobs_unsafe from a flavour. The build timed out with this.
- no portrevision bump as no pkg content changes.

PR:     296127
DeltaFile
+3-1databases/mongodb70/distinfo
+1-2databases/mongodb70/Makefile
+4-32 files

FreeBSD/ports ddaee92www/nextcloud-appointments distinfo Makefile

www/nextcloud-appointments: Update to 2.7.4
DeltaFile
+3-3www/nextcloud-appointments/distinfo
+1-1www/nextcloud-appointments/Makefile
+4-42 files

NetBSD/pkgsrc T65TSpqdevel/openocd Makefile, lang/jimtcl buildlink3.mk Makefile

   jimtcl: bump BUILDLINK_API_DEPENDS to 0.83nb1.

   The current devel/openocd (0.12.0) fails to compile with jimtcl < 0.83,
   but since the BUILDLINK_API_DEPENDS was 0.80nb1, you would not notice
   the failure unless you had an older version of jimtcl already installed.

   So, jimtcl is now 0.83nb1, BUILDLINK_API_DEPENDS set to match, and openocd
   bumped to 0.12.0nb1 to force the correct dependency to be recorded.
VersionDeltaFile
1.4+2-2lang/jimtcl/buildlink3.mk
1.15+2-1lang/jimtcl/Makefile
1.12+2-1devel/openocd/Makefile
+6-43 files

FreeBSD/ports a5ad594graphics/mesa-dri Makefile, graphics/mesa-libs Makefile

graphics/mesa-{dri,libs}: Fix vaapi for AMD

VA bits end up being compiled into the libgallium.so giant library, which is
shipped by mesa-libs. This means that we should make libva an unconditional
build dep for mesa-libs. In turn this makes no sense to disable VA in mesa-dri.

Luckily, libva is a pretty thin dep.

Reported by:    flo
DeltaFile
+2-12graphics/mesa-dri/Makefile
+4-2graphics/mesa-libs/Makefile
+6-142 files

LLVM/project 3c33c36libcxx/src atomic.cpp

[libc++] Use public os_sync API instead of private __ulock on newer Apple platforms (#202519)

The atomic wait and wake implementation on Apple platforms currently
relies on `__ulock_wait` and `__ulock_wake`, which are private kernel
APIs. This is a problem for anyone shipping apps through the App Store
since Apple flags private symbol usage during review.

Starting with macOS 14.4 and iOS 17.4, Apple ships public replacements
through `os_sync_wait_on_address` and `os_sync_wake_by_address_any/all`
in `<os/os_sync_wait_on_address.h>`. These cover the same functionality
and are documented, stable, and safe for App Store submissions.

This patch makes use of the public APIs instead of the private ones
whenever the underlying OS permits it.

This takes over #182947.
Fixes #182908
Fixes #146142

Co-authored-by: Bbn08 <atrancendentbeing at gmail.com>
DeltaFile
+87-15libcxx/src/atomic.cpp
+87-151 files

LLVM/project e8a022alibc/include/llvm-libc-macros/linux sys-ioctl-macros.h

[libc] Include linux headers to get ioctl macros (#204555)

Linux has many existing ioctls and keeps adding them, so a
hand-maintained list would always be out of date. Additionally, some
ioctls have architecture specific numbers (some in a very subtle way --
by having the number depend on the size of a structure).

asm/ioctls.h and linux/sockios.h are pretty clean, and are already
included by glibc, so we can just do the same to get the latest
definitions.
DeltaFile
+2-8libc/include/llvm-libc-macros/linux/sys-ioctl-macros.h
+2-81 files

OpenBSD/src rMCLCdssys/miscfs/fuse fuse_lookup.c

   Consistently use convenience variables rather then referencing
   members of the input structs in fuse_lookup(). No functional change.

   OK claudio@
VersionDeltaFile
1.25+7-7sys/miscfs/fuse/fuse_lookup.c
+7-71 files

LLVM/project 23abfa0mlir/include/mlir/Dialect/Tosa/IR TosaTypesBase.td, mlir/test/Conversion/TosaToArith tosa-to-arith.mlir

[mlir][tosa] Allow rank-0 vector operands in tosa.apply_scale (#199924)

I was facing a bug that can be reproduced this way:

```mlir
 // RUN:  mlir-opt --transform-interpreter tosa_apply_scale_rank0_repro.mlir
  #map        = affine_map<(d0) -> (d0)>
  #map_scalar = affine_map<(d0) -> ()>

  func.func @repro(%input: tensor<64xi32>, %scalar_t: tensor<i32>,
                   %out_init: tensor<64xi8>) -> tensor<64xi8> {
    %c31_i8     = arith.constant 31 : i8
    %cScale_i32 = arith.constant -1010580540 : i32

    %tile_out = linalg.generic
      { indexing_maps = [#map, #map_scalar, #map],
        iterator_types = ["parallel"] }
      ins(%input, %scalar_t : tensor<64xi32>, tensor<i32>)
      outs(%out_init : tensor<64xi8>) {

    [52 lines not shown]
DeltaFile
+10-0mlir/test/Conversion/TosaToArith/tosa-to-arith.mlir
+1-1mlir/include/mlir/Dialect/Tosa/IR/TosaTypesBase.td
+11-12 files

LLVM/project d77f3bfllvm/utils/gn/secondary/clang/tools/clang-ssaf-format BUILD.gn

[gn] port 53dabae40fb3a8514 more (#204578)
DeltaFile
+1-0llvm/utils/gn/secondary/clang/tools/clang-ssaf-format/BUILD.gn
+1-01 files

FreeBSD/ports 84f7eb7sysutils/u-boot-rpi-arm64/files rpi_arm64_fragment, sysutils/u-boot-rpi4/files rpi4_fragment

sysutil/u-boot-rpi*: zap CONFIG_ENV_FAT_DEVICE_AND_PART

This is no longer needed with modern U-Boot and it's inaccurate for the
modern RPi.  Leave the config var around for now as a hint in case
someone cares, but empty it out to avoid breaking things.

PR:             268630
Approved by:    uboot (manu)
DeltaFile
+1-1sysutils/u-boot-rpi4/files/rpi4_fragment
+1-1sysutils/u-boot-rpi-arm64/files/rpi_arm64_fragment
+2-22 files

LLVM/project 1343b64compiler-rt/cmake builtin-config-ix.cmake

[compiler-rt] Fix default builtins target _Float16 detection on x86_64/i386 (#204474)
DeltaFile
+6-0compiler-rt/cmake/builtin-config-ix.cmake
+6-01 files

LLVM/project 7fda520llvm/utils/gn/secondary/llvm/unittests/Transforms/Vectorize BUILD.gn

[gn build] Port 4d812375c174 (#204575)
DeltaFile
+0-1llvm/utils/gn/secondary/llvm/unittests/Transforms/Vectorize/BUILD.gn
+0-11 files

LLVM/project 8b0462fllvm/utils/gn/secondary/clang/lib/Driver BUILD.gn, llvm/utils/gn/secondary/clang/lib/FrontendTool BUILD.gn

[gn] port 53dabae40fb3a8514 (ssaf/SourceTransformation) (#204574)
DeltaFile
+12-0llvm/utils/gn/secondary/clang/lib/ScalableStaticAnalysisFramework/SourceTransformation/BUILD.gn
+4-0llvm/utils/gn/secondary/clang/unittests/ScalableStaticAnalysisFramework/BUILD.gn
+1-0llvm/utils/gn/secondary/clang/tools/clang-ssaf-analyzer/BUILD.gn
+1-0llvm/utils/gn/secondary/clang/lib/Driver/BUILD.gn
+1-0llvm/utils/gn/secondary/clang/lib/FrontendTool/BUILD.gn
+1-0llvm/utils/gn/secondary/clang/tools/clang-ssaf-linker/BUILD.gn
+20-06 files

LLVM/project 5fe9132llvm/utils/gn/secondary/clang/lib/ScalableStaticAnalysisFramework/Core BUILD.gn

[gn build] Port 6e21a04a5a96 (#204576)
DeltaFile
+1-0llvm/utils/gn/secondary/clang/lib/ScalableStaticAnalysisFramework/Core/BUILD.gn
+1-01 files

LLVM/project df06afbllvm/lib/Target/AMDGPU SIWholeQuadMode.cpp, llvm/test/CodeGen/AMDGPU wqm.mir licm-wwm.mir

[AMDGPU] Mark all instructions in WWM region as convergent

Mark instructions between ENTER_STRICT_WWM and EXIT_STRICT_WWM as
convergent, so they don't get moved out of the whole wave mode region
(see the licm-wwm.mir test). This doesn't automagically fix all our
woes, since things can still be moved out of the region before we even
run si-wqm, but there are rumours about moving WWM formation earlier
anyway.

This is not a substitute for proper WWM support - in particular, this
would inhibit most optimizations inside WWM regions with complex control
flow. Right now most WWM is relatively limited in size and complexity,
so I think this is acceptable until we get a more principled solution.

I haven't thought too much about whether or not we need this for WQM as
well.

Assisted by: Claude Sonnet

commit-id:9204c7e2
DeltaFile
+17-17llvm/test/CodeGen/AMDGPU/wqm.mir
+24-1llvm/test/CodeGen/AMDGPU/licm-wwm.mir
+5-5llvm/test/CodeGen/AMDGPU/wqm-debug-instr.mir
+8-0llvm/lib/Target/AMDGPU/SIWholeQuadMode.cpp
+2-2llvm/test/CodeGen/AMDGPU/si-init-whole-wave.mir
+56-255 files

LLVM/project 28ac70ellvm/docs AMDGPUExecutionSynchronization.rst

[AMDGPU][doc] Refactor Barrier Execution Model

Remove everything that has to do with named barriers and put it in a series of model extensions specific to /sbarrier/named-barriers.

I had to change a few things to make it fit, in summary:

Base Model:

* Stylistic changes that make it easier to refer to specific rules. Each rule is in a rubric instead of a bullet point.
* (-) No longer defines `barrier-mutually-exclusive`
* (-) No longer defines barrier `join` and any associated rule.

New named barrier extensions
* Define "named barrier" as a sub-type of barrier objects. This makes barrier-mutually-exclusive redundant.
* Define barrier join as an op that can exclusively be done on `named barrier objects`.
* Define rules relating to join and its ordering with other barrier operations

Following these changes, the target tables changed a bit as well.


    [2 lines not shown]
DeltaFile
+200-154llvm/docs/AMDGPUExecutionSynchronization.rst
+200-1541 files

LLVM/project 60416cfopenmp/runtime/src kmp_traits.cpp kmp_traits.h, openmp/runtime/src/i18n en_US.txt

[libomp] Parse OMP_DEFAULT_DEVICE with new device trait parser

... but do not yet expose the new functionalities to the user. This is a
backward compatible update that is going to be followed by the step to
the OpenMP 6.0 semantics as defined in 4.3.8.
DeltaFile
+105-0openmp/runtime/unittests/Traits/TestOMPTraitParser.cpp
+24-0openmp/runtime/src/kmp_traits.cpp
+8-0openmp/runtime/src/kmp_traits.h
+3-2openmp/runtime/src/kmp_settings.cpp
+3-0openmp/runtime/src/i18n/en_US.txt
+143-25 files

LLVM/project 514190copenmp/runtime/src kmp_traits.cpp kmp_traits.h, openmp/runtime/src/i18n en_US.txt

move parse_single_device to other PR
DeltaFile
+0-80openmp/runtime/unittests/Traits/TestOMPTraitParser.cpp
+0-19openmp/runtime/src/kmp_traits.cpp
+0-7openmp/runtime/src/kmp_traits.h
+0-1openmp/runtime/src/i18n/en_US.txt
+0-1074 files

LLVM/project f39ddcbclang/lib/Driver/ToolChains AMDGPU.cpp, llvm/include/llvm/TargetParser AMDGPUTargetParser.def

AMDGPU: Add subtarget feature for controllable xnack modes

This replaces the previously removed xnack-any-only feature,
with the inversion xnack-on-off-modes. All pre-gfx12.5 xnack
targets support the controllable mode. Ignore explicitly
set xnack settings the same way as is done for xnack requests
on other unsupported targets.
DeltaFile
+22-22llvm/include/llvm/TargetParser/AMDGPUTargetParser.def
+13-11llvm/lib/Target/AMDGPU/Utils/AMDGPUBaseInfo.cpp
+22-0llvm/test/CodeGen/AMDGPU/target-id-xnack-always-on.ll
+14-6llvm/lib/Target/AMDGPU/AMDGPU.td
+2-8llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.h
+4-3clang/lib/Driver/ToolChains/AMDGPU.cpp
+77-504 files not shown
+82-5710 files

LLVM/project 46f3a3ellvm/lib/Target/AMDGPU SIWholeQuadMode.cpp, llvm/test/CodeGen/AMDGPU wqm.mir licm-wwm.mir

[AMDGPU] Mark all instructions in WWM region as convergent

Mark instructions between ENTER_STRICT_WWM and EXIT_STRICT_WWM as
convergent, so they don't get moved out of the whole wave mode region
(see the licm-wwm.mir test). This doesn't automagically fix all our
woes, since things can still be moved out of the region before we even
run si-wqm, but there are rumours about moving WWM formation earlier
anyway.

This is not a substitute for proper WWM support - in particular, this
would inhibit most optimizations inside WWM regions with complex control
flow. Right now most WWM is relatively limited in size and complexity,
so I think this is acceptable until we get a more principled solution.

I haven't thought too much about whether or not we need this for WQM as
well.

Assisted by: Claude Sonnet

commit-id:9204c7e2
DeltaFile
+17-17llvm/test/CodeGen/AMDGPU/wqm.mir
+26-1llvm/test/CodeGen/AMDGPU/licm-wwm.mir
+5-5llvm/test/CodeGen/AMDGPU/wqm-debug-instr.mir
+8-0llvm/lib/Target/AMDGPU/SIWholeQuadMode.cpp
+2-2llvm/test/CodeGen/AMDGPU/si-init-whole-wave.mir
+58-255 files

LLVM/project 904ce28llvm/include/llvm/CodeGen MachineInstr.h, llvm/test/CodeGen/AMDGPU isel-amdgpu-cs-chain-cc.ll

Repurpose MIFlag::NoConvergent

The NoConvergent MIFlag allows us to mark specific instances of
convergent (as indicated by their MCID) MachineInstrs as not convergent.
Sometimes it's useful to do the opposite as well - mark certain
instances of instructions that are not normally convergent as
convergent (for instance inside WWM regions on AMDGPU).
This patch renames the NoConvergent flag to OverrideConvergence. This
can be set to communicate that if the opcode is usually convergent, then
this particular instance of it isn't, and the other way around. When
changing the opcode of an instruction, we first check if the new opcode
has the same "convergence" as the old one - if it does, then we preserve
the flag, otherwise we clear it since we can get the correct convergence
from the opcode now.

Assisted by: Claude Sonnet

commit-id:93c99000
DeltaFile
+92-92llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call.ll
+50-50llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-return-values.ll
+43-44llvm/include/llvm/CodeGen/MachineInstr.h
+20-20llvm/test/CodeGen/AMDGPU/GlobalISel/irtranslator-call-implicit-args.ll
+16-16llvm/test/CodeGen/AMDGPU/isel-amdgpu-cs-chain-cc.ll
+10-10llvm/test/CodeGen/AMDGPU/GlobalISel/dereferenceable-declaration.ll
+231-23224 files not shown
+293-30830 files

LLVM/project 2062fc6llvm/test/CodeGen/AMDGPU/GlobalISel dropped_debug_info_assert.ll

[AMDGPU] Run update script on test. NFC

There's some bogus whitespace in the generated CHECKs that changes when
touching the test.

commit-id:150473b0
DeltaFile
+37-37llvm/test/CodeGen/AMDGPU/GlobalISel/dropped_debug_info_assert.ll
+37-371 files

LLVM/project 6236b9allvm/lib/Target/X86 X86CompressEVEX.cpp, llvm/test/CodeGen/X86 compress-evex-vpmov-kill.mir

[X86] Fix stale kill flag when folding VPMOV*2M + KMOV to VMOVMSK (#204342)

tryCompressVPMOVPattern folds VPMOV*2M + KMOV into a single VMOVMSK in
place: it changes the KMOV's opcode and repoints its source operand from
the mask k-register to the XMM source via MachineOperand::setReg().

setReg() only changes the register number and keeps the operand's other
flags, so the kill flag computed for the mask ("killed $k0") is reused
for the XMM source. When the source is still live this marks it killed,
which the machine verifier reports as a use of an undefined register.

We should instead use the kill flag from the VPMOV's source operand. The
forward scan already guarantees the source is not redefined between the
VPMOV and the KMOV, so the VPMOV's flag is correct at the relocated
read.

Found via @jlebar's X86 LLVM bug-hunt / FuzzX effort:

https://github.com/SemiAnalysisAI/FuzzX/tree/master/x86/bugs/043-compress-evex-vpmov-srcvec-clobber-kmov

cc @jlebar
DeltaFile
+37-0llvm/test/CodeGen/X86/compress-evex-vpmov-kill.mir
+5-1llvm/lib/Target/X86/X86CompressEVEX.cpp
+42-12 files

LLVM/project f6589a1llvm/lib/Target/AMDGPU SIInsertWaitcnts.cpp

Adjust comment
DeltaFile
+2-2llvm/lib/Target/AMDGPU/SIInsertWaitcnts.cpp
+2-21 files