LLVM/project a045cb5llvm/lib/Target/DirectX DXILShaderFlags.cpp

Update size check in DXILShaderFlags
DeltaFile
+1-1llvm/lib/Target/DirectX/DXILShaderFlags.cpp
+1-11 files

LLVM/project 351d869llvm/lib/Target/X86 X86TargetTransformInfo.cpp, llvm/test/Analysis/CostModel/X86 zext-gep-index.ll

[X86][CostModel] Free a clean narrow zext used as a GEP index (#216256)

`getCastInstrCost` already treats a narrow (i8/i16) zext of a load as
free (the extension folds into the load). This extends the same
movzx-free reasoning to any narrow zext whose single use is a **GEP
index** with a provably-clean source — a load, a `zeroext` argument, or
known-zero high bits. On x86-64 `[base + index*scale + disp]` reads the
index at full width, so a clean narrow index needs no `movzx`. A dirty
source (e.g. an `i16 add` used only as an index) still needs one and is
unchanged. The cost is consumed by SimplifyCFG's two-entry-PHI fold
budget (`TCK_SizeAndLatency`); overcharging a clean index by one kept
small select diamonds branched on x86.

Test: `llvm/test/Analysis/CostModel/X86/zext-gep-index.ll` — fails on
trunk
(clean known-bits index reports 1), passes with the patch.

---------

Co-authored-by: Cursor <cursoragent at cursor.com>
DeltaFile
+141-0llvm/test/Analysis/CostModel/X86/zext-gep-index.ll
+31-0llvm/lib/Target/X86/X86TargetTransformInfo.cpp
+172-02 files

LLVM/project 2b5f970clang/lib/Driver/ToolChains Clang.cpp, clang/lib/Driver/ToolChains/Arch RISCV.cpp

[RISCV] Move -mtune=native expansion into riscv::getRISCVTuneCPU. NFC (#215891)

Previously it was applied at one of the call sites. Applying it inside
makes it more clear how it is supposed to interact with
-mexperimental-mtune-syntax
DeltaFile
+13-7clang/lib/Driver/ToolChains/Arch/RISCV.cpp
+3-6clang/lib/Driver/ToolChains/Clang.cpp
+6-0clang/test/Driver/riscv-mtune-tune-features.c
+22-133 files

OpenBSD/ports wA4WA1ydevel/mergiraf Makefile crates.inc

   Update to mergiraf 0.19

   https://codeberg.org/mergiraf/mergiraf/releases/tag/v0.19.0
VersionDeltaFile
1.6+38-32devel/mergiraf/distinfo
1.6+18-15devel/mergiraf/crates.inc
1.7+1-1devel/mergiraf/Makefile
+57-483 files

LLVM/project 6a114fbllvm/unittests/ExecutionEngine/Orc SymbolLookupSetTest.cpp

[ORC] Extend SymbolLookupSet unit test coverage (#216617)

Covers the rest of the public API: construction, add/append, remove,
remove_if, forEachWithRemoval, getSymbolNames, sortByName, sortByAddress
and containsDuplicates.
DeltaFile
+392-9llvm/unittests/ExecutionEngine/Orc/SymbolLookupSetTest.cpp
+392-91 files

LLVM/project d2028c3llvm/include/llvm/Target TargetInstrPredicate.td, llvm/lib/Target/AArch64 AArch64SchedPredicates.td

[TableGen] Add checks for CheckRegOperand/CheckImmOperand (#215230)

`CheckRegOperand`, `CheckImmOperand`, and their related predicates
currently call `getReg()` and `getImm()` without first verifying that
the operand is a register or an immediate. Users must explicitly use
`CheckIsRegOperand` and `CheckIsImmOperand` to avoid errors for other
operand kinds, as exposed by #213815.

This PR adds default `isReg()` and `isImm()` checks to those predicates
before accessing the corresponding values, and also removes redundant
`CheckIsRegOperand` and `CheckIsImmOperand` checks from existing users
in the X86, ARM, and RISCV backends.
DeltaFile
+285-0llvm/test/TableGen/PredicateExpander.td
+114-50llvm/utils/TableGen/Common/PredicateExpander.cpp
+67-41llvm/include/llvm/Target/TargetInstrPredicate.td
+37-48llvm/lib/Target/AArch64/AArch64SchedPredicates.td
+6-7llvm/utils/TableGen/Common/PredicateExpander.h
+5-5llvm/test/TableGen/ResolveSchedClass.td
+514-1516 files not shown
+520-18112 files

LLVM/project 7fb4cc0llvm/lib/Target/RISCV RISCVInstrInfo.cpp, llvm/test/CodeGen/RISCV optimize-cond-branch-undef.mir

RISCV: Fix optimizeCondBranch crash on an undef register

Found by AI while working on something else.

Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
DeltaFile
+36-0llvm/test/CodeGen/RISCV/optimize-cond-branch-undef.mir
+6-1llvm/lib/Target/RISCV/RISCVInstrInfo.cpp
+42-12 files

LLVM/project d04e49dmlir/include/mlir-c Interfaces.h, mlir/lib/Bindings/Python DialectTransform.cpp IRInterfaces.cpp

[MLIR][CAPI][Python] Add support for querying memory effect instances (#213459)

The current memory-effect bindings are write-only. Python interface
implementations can append effects to a temporary
`MemoryEffectInstancesList`, but callers cannot inspect an effect
instance or ask an operation for its effects.

This patch adds the missing query support to the C API and exposes it in
Python. Effect instances can be inspected and copied, and the Python
APIs use regular `MemoryEffectInstance` objects and Python-native
`list`s. The Transform helpers follow the same model.

`MemoryEffectInstancesList` is **removed** from both the C and Python
APIs. Python implementations and helpers now return effects instead of
mutating a supplied list, while the C API passes effects through
callbacks (`MlirMemoryEffectInstancesCallback`).

When an API produces a batch of effects, it invokes
`MlirMemoryEffectInstancesCallback` with a count and an array. The

    [15 lines not shown]
DeltaFile
+149-28mlir/lib/Bindings/Python/IRInterfaces.cpp
+97-34mlir/test/python/dialects/memory_effects_op_interface.py
+87-4mlir/test/CAPI/ir.c
+69-16mlir/include/mlir-c/Interfaces.h
+68-5mlir/lib/CAPI/Interfaces/Interfaces.cpp
+44-21mlir/lib/Bindings/Python/DialectTransform.cpp
+514-1089 files not shown
+649-15915 files

LLVM/project 77bdc16clang/lib/CodeGen BackendUtil.cpp

[dyndbg][Clang] Avoid memcpy on nullptr from #216307 (#216625)

As reported in
https://github.com/llvm/llvm-project/pull/216307#issuecomment-5311023374,
the new tests fail on UBSan buildbots (e.g.,
https://lab.llvm.org/buildbot/#/builders/25/builds/19323) because the
directory may be empty (only the file is initialized [*]). The StringRef
from getDirectory() would be default-initialized, and hashing it results
in memcpy'ing from a null pointer.

This patch attempts to fix-forward by not hashing the output of
getDirectory() if it is empty.

[*] e.g., `!3 = !DIFile(filename:
"/usr/local/google/home/thurston/llvm-projectA/clang/test/DebugInfo/DynamicDebugging/<stdin>",
directory: "")`
DeltaFile
+3-1clang/lib/CodeGen/BackendUtil.cpp
+3-11 files

FreeBSD/src 14e3daacontrib/sqlite3 sqlite3rc.h VERSION, contrib/sqlite3/autosetup sqlite-config.tcl

sqlite3: Vendor import of sqlite3 3.53.3

Release notes at https://www.sqlite.org/releaselog/3_53_3.html.

Obtained from:  https://www.sqlite.org/2026/sqlite-autoconf-3530300.tar.gz

MFC after:      2 weeks

Merge commit 'e698feec080925c6cffa9ec31be884daa5cea536'
DeltaFile
+1,198-445contrib/sqlite3/sqlite3.c
+109-44contrib/sqlite3/shell.c
+21-7contrib/sqlite3/sqlite3.h
+6-2contrib/sqlite3/autosetup/sqlite-config.tcl
+1-1contrib/sqlite3/sqlite3rc.h
+1-1contrib/sqlite3/VERSION
+1,336-5006 files

LLVM/project c11305ellvm/lib/CodeGen MachineSink.cpp, llvm/test/CodeGen/X86 machinesink-coalesce-undef.mir

CodeGen: Fix MachineSink trivial coalescing crash on an undef register

Fix unchecked getVRegDef use. Found by AI while working on something else.

Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
DeltaFile
+39-0llvm/test/CodeGen/X86/machinesink-coalesce-undef.mir
+1-1llvm/lib/CodeGen/MachineSink.cpp
+40-12 files

LLVM/project ddba329llvm/include/llvm/ADT FoldingSet.h, llvm/lib/Support FoldingSet.cpp

[ADT] Clean up FoldingSet.* (NFC) (#216619)

This patch cleans up minor issues in FoldingSet.*.

- FoldingSetBase::NodeID never existed in the history of FoldingSet.
  The comment should refer to FoldingSetNodeID instead.

- GetBucketPtr lost the first line of its doc comment on February 4,
  2008 in commit e2887863563f, leaving only "testing.".

- ImmutableSetTest.cpp was relying on FoldingSet.h to include
  ArrayRef.h.

Other changes should be self-explanatory.

Assisted-by: Antigravity
DeltaFile
+5-6llvm/include/llvm/ADT/FoldingSet.h
+1-0llvm/unittests/ADT/ImmutableSetTest.cpp
+1-0llvm/lib/Support/FoldingSet.cpp
+7-63 files

FreeBSD/ports f3ebb9fdevel/py-expression distinfo Makefile

devel/py-expression: Update to 5.7.0

While here, add USE_PYTHON=pytest.

Changelog: https://github.com/dbrattli/Expression/blob/v5.7.0/CHANGELOG.md

Reported by:    portscout
DeltaFile
+5-4devel/py-expression/Makefile
+3-3devel/py-expression/distinfo
+8-72 files

FreeBSD/ports fd3fd42www/bozohttpd Makefile, www/bozohttpd/files patch-auth-bozo.c patch-bozohttpd.c

www/bozohttpd: Use blocklist

Starting from FreeBSD version 1500000, prefer the new blocklist
nomenclature.

Once older versions are no longer supported, we should use blocklist
exclusively.

PR:             294080
DeltaFile
+56-0www/bozohttpd/files/blacklist-patches/patch-bozohttpd.8
+0-54www/bozohttpd/files/patch-bozohttpd.8
+0-53www/bozohttpd/files/patch-bozohttpd.c
+53-0www/bozohttpd/files/blacklist-patches/patch-bozohttpd.c
+12-5www/bozohttpd/Makefile
+0-15www/bozohttpd/files/patch-auth-bozo.c
+121-1275 files not shown
+160-14711 files

FreeBSD/ports 8aca7f6www/pecl-solr distinfo pkg-descr, www/pecl-solr/files extra-src__php_solr.h

www/php-solr: update to 2.9.3, also move to new php extension standard.

PR:             297611
DeltaFile
+0-28www/pecl-solr/Makefile
+25-0www/php-solr/Makefile
+0-11www/pecl-solr/files/extra-src__php_solr.h
+0-4www/pecl-solr/pkg-descr
+4-0www/php-solr/pkg-descr
+0-3www/pecl-solr/distinfo
+29-463 files not shown
+34-479 files

FreeBSD/ports 60abebbdevel/py-uvloop Makefile distinfo

devel/py-uvloop: Update to version 0.22.1 with python314 free-threading support

PR:             ports/294535
Approved by:    maintainer (farrokhi)
DeltaFile
+3-3devel/py-uvloop/distinfo
+1-2devel/py-uvloop/Makefile
+4-52 files

OpenBSD/ports y7BFQIgdevel/apr-util Makefile

   With base-gcc apr-util throws
   error: missing binary operator before token "("

   Move to ports-gcc on base-gcc arches to fix build on sparc64
VersionDeltaFile
1.65+4-0devel/apr-util/Makefile
+4-01 files

LLVM/project 3cc0457clang/include/clang/CIR LoweringHelpers.h, clang/lib/CIR/Lowering LoweringHelpers.cpp

[CIR] Correct union lowering behavior re-padding (#216349)

Most of the code that CIR lowers to LLVM counts on the fact that our
alignnments are correct/calculated in LLVM to get our layout correctly.
This works for the most part, and unions have the storage type of the
'highest' alignment type.

However, when creating a constant, we have to convert the type of the
union to have a 'storage' type that matches the data being inserted (not
the union's storage type!). The result was that if we had a storage type
where the alignment was smaller than the actual storage type, LLVM would
mis-calculate the padding.

This patch adds the padding explicitly when we make that conversion to
get the alignment set up correctly.

Note: there is one mild IR-equivilency-regression to this patch. There
isn't really a great way to tell the difference between a
union-tail-padding needing zero-init vs undef-init in this case. This

    [2 lines not shown]
DeltaFile
+103-19clang/lib/CIR/Lowering/LoweringHelpers.cpp
+56-3clang/test/CIR/CodeGen/union-agg-init.c
+14-3clang/lib/CIR/Lowering/DirectToLLVM/LowerToLLVM.cpp
+13-0clang/test/CIR/CodeGen/union-agg-init.cpp
+8-0clang/include/clang/CIR/LoweringHelpers.h
+3-3clang/test/CIR/CodeGen/unions-with-zero-init.cpp
+197-281 files not shown
+198-297 files

LLVM/project 9cd4a3dclang/test/CIR/CodeGen vtable-emission.cpp vtt.cpp, clang/test/CIR/CodeGenCXX vtable-linkage.cpp

[CIR] Fix the 'constant'-ness of vtable-variables (#216434)

The createOrReplaceCXXRuntimeVariable sets the variable to be 'constant'
in classic codegen, this sets that right. However, 1 use of it (in
buildVTablePointer) doesn't match classic-codegen (it instead calls
getOrInsertGlobal directly), so this patch adds a bit of a fixup there
to minimize the impact of this change.
DeltaFile
+57-57clang/test/CIR/CodeGenCXX/vtable-linkage.cpp
+10-10clang/test/CIR/CodeGen/thunks.cpp
+5-9clang/test/CIR/CodeGen/vtable-linkage-explicit-instantiation.cpp
+6-6clang/test/CIR/CodeGen/vtt.cpp
+6-6clang/test/CIR/CodeGen/multi-vtable.cpp
+3-6clang/test/CIR/CodeGen/vtable-emission.cpp
+87-948 files not shown
+105-10714 files

FreeBSD/src 3782626sys/dev/asmc asmcmmio.c asmc.c

asmc: prefer MMIO backend over PIO when both are present

T2, T1, and some pre-T1 Macs advertise a legacy PIO
range in the SMC ACPI _CRS alongside a live MMIO window, but the
silicon behind the PIO range is bogus.

Try MMIO first, validate via LDKN >= 2, fall back to PIO if that
fails or no MMIO resource is present. Drop "(T2)" from the backend
message since MMIO isn't T2-exclusive.

MFC: 1 week
Reviewed by:    ngie
Differential Revision:  https://reviews.freebsd.org/D58839
DeltaFile
+10-8sys/dev/asmc/asmc.c
+1-1sys/dev/asmc/asmcmmio.c
+11-92 files

FreeBSD/ports 387b7d6java/netbeans Makefile distinfo

java/netbeans: Update 30 => 31

Changelog:
https://github.com/apache/netbeans/releases/tag/31

PR:             297602
Sponsored by:   UNIS Labs
DeltaFile
+28-26java/netbeans/pkg-plist
+3-3java/netbeans/distinfo
+1-1java/netbeans/Makefile
+32-303 files

LLVM/project a878778mlir/include/mlir/Interfaces ControlFlowInterfaces.h, mlir/lib/Dialect/SCF/IR SCF.cpp

[mlir] Fix RemoveDeadRegionBranchOpSuccessorInputs producing invalid scf.for

RemoveDeadRegionBranchOpSuccessorInputs builds its tied-value sets from
RegionBranchOpInterface::getSuccessorOperandInputMapping, which is derived from
getSuccessorRegions. For an scf.for with a statically-known trip count of 1,
getSuccessorRegions drops the region->region back edge (the loop provably never
iterates back). That back edge is what forwards a yield operand to the region
iter_args, so without it an iter_arg and its corresponding op result are no
longer tied through a shared operand. The pattern then removes a dead iter_arg
without its (structurally required) result, producing an scf.for with
mismatched loop-carried counts:

    'scf.for' op mismatch in number of loop-carried values and defined values

The greedy driver repairs this on a later iteration (InlineRegionBranchOp folds
the single-trip loop), so it is only observed with
MLIR_ENABLE_EXPENSIVE_PATTERN_API_CHECKS, which verifies the IR after every
pattern application. It shows up across Linalg tiling / pack-unpack /
convolution lowering and scf loop canonicalization; see issue #163599.

    [15 lines not shown]
DeltaFile
+29-7mlir/lib/Interfaces/ControlFlowInterfaces.cpp
+25-2mlir/lib/Dialect/SCF/IR/SCF.cpp
+17-2mlir/include/mlir/Interfaces/ControlFlowInterfaces.h
+71-113 files

FreeBSD/ports d16294bdevel/py-ty Makefile Makefile.crates

devel/py-ty: Update to 0.0.72

Changelog: https://github.com/astral-sh/ty/blob/0.0.72/CHANGELOG.md

Reported by:    portscout
DeltaFile
+11-3devel/py-ty/distinfo
+4-0devel/py-ty/Makefile.crates
+1-1devel/py-ty/Makefile
+16-43 files

DragonFlyBSD/src cea9f57test/testcases/libnvmm h_mem_assist.c h_mem_assist_asm.S

testcases/libnvmm: Rename our extra tests to avoid conflicts
DeltaFile
+8-8test/testcases/libnvmm/h_mem_assist_asm.S
+7-8test/testcases/libnvmm/h_mem_assist.c
+15-162 files

DragonFlyBSD/src c620eectest/testcases/libnvmm h_mem_assist.c h_io_assist.c

testcases/libnvmm: Extract OS-specific bits into h_os.h
DeltaFile
+91-0test/testcases/libnvmm/h_os.h
+3-46test/testcases/libnvmm/h_io_assist.c
+3-45test/testcases/libnvmm/h_mem_assist.c
+97-913 files

DragonFlyBSD/src dad22e4test/testcases/libnvmm h_io_assist.c h_mem_assist.c

testcases/libnvmm: Print more info and report total failures

* Print a few more details in the output logs.
* Run all tests to completeion and report the total number of failures
  at the end.
DeltaFile
+36-13test/testcases/libnvmm/h_mem_assist.c
+20-8test/testcases/libnvmm/h_io_assist.c
+56-212 files

DragonFlyBSD/src da9c391test/testcases/libnvmm h_mem_assist.c h_io_assist.c

testcases/libnvmm: Add CFLAGS+=-g and enable WARNS=6
DeltaFile
+1-1test/testcases/libnvmm/h_mem_assist.c
+1-1test/testcases/libnvmm/h_io_assist.c
+2-0test/testcases/libnvmm/Makefile.inc
+4-23 files

LLVM/project 62540c7llvm/include/llvm/IR RuntimeLibcalls.td, llvm/test/CodeGen/X86 fp128-libcalls-gnu.ll

RuntimeLibcalls: Provide fp128 long double libcalls on X86

16a8d8d038a3  removed the l-suffixed long double math functions
from the default set and re-added them per-target gated on
isLongDoubleF128, but X86 was not given the re-add. On targets
whose long double is fp128 (e.g. x86_64 Android/OHOS) this dropped
the fp128 l-suffixed libcalls.

Fixes the regression reported on #214944.

Co-authored-by: Claude (Opus 4.8) <noreply at anthropic.com>
DeltaFile
+264-4llvm/test/CodeGen/X86/fp128-libcalls-gnu.ll
+8-0llvm/include/llvm/IR/RuntimeLibcalls.td
+272-42 files

LLVM/project 6530e27llvm/include/llvm/CodeGen TargetLowering.h, llvm/lib/CodeGen/SelectionDAG SelectionDAGBuilder.cpp

[CodeGen] Pass the atomic instruction to supportsUnalignedAtomics
DeltaFile
+2-2llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
+3-1llvm/include/llvm/CodeGen/TargetLowering.h
+5-32 files

LLVM/project 4dc3ef8mlir/lib/Interfaces ControlFlowInterfaces.cpp

[mlir] Fix RemoveDeadRegionBranchOpSuccessorInputs producing invalid scf.for

RemoveDeadRegionBranchOpSuccessorInputs builds its tied-value sets from
RegionBranchOpInterface::getSuccessorOperandInputMapping, which is derived from
getSuccessorRegions. For an scf.for with a statically-known trip count of 1,
getSuccessorRegions drops the region->region back edge (the loop provably never
iterates back). That back edge is what forwards a yield operand to the region
iter_args, so without it an iter_arg and its corresponding op result are no
longer tied through a shared operand. The pattern then removes a dead iter_arg
without its (structurally required) result, producing an scf.for with
mismatched loop-carried counts:

    'scf.for' op mismatch in number of loop-carried values and defined values

The greedy driver repairs this on a later iteration, so it is only observed
with MLIR_ENABLE_EXPENSIVE_PATTERN_API_CHECKS (which verifies the IR after
every pattern application). It shows up across Linalg tiling / pack-unpack /
convolution lowering and scf loop canonicalization; see issue #163599.


    [6 lines not shown]
DeltaFile
+65-0mlir/lib/Interfaces/ControlFlowInterfaces.cpp
+65-01 files