packages: Add dependency from rc to mtree
/etc/rc.d/var_run uses mtree, which is in the devel set and isn't
installed as part of either minimal or optional, so add a manual
dependency.
Reviewed by: des, bapt, emaste
Differential Revision: https://reviews.freebsd.org/D54540
Sponsored by: https://www.patreon.com/bsdivy
packages: Move xz to the minimal set
pkg(8), via its daily periodic script, requires xz. We don't have
a way to encode dependencies from ports on base packages right now,
so instead move xz to the minimal set so it's always installed.
This isn't an ideal solution, but it's justified in this case since
pkg(8) is always installed, so having its dependencies always
installed is acceptable.
(Following discusson on the diff, new versions of pkg have now been
changed to use zstd instead of xz, but we still think xz is useful
enough to keep in minimal.)
MFC after: 1 week (stable/15 only)
Reviewed by: des, bapt, emaste
Differential Revision: https://reviews.freebsd.org/D55630
Sponsored by: https://www.patreon.com/bsdivy
[clang] Fix AArch64 -ffixed-x help text (#188911)
Fix the documented support set for AArch64 `-ffixed-xN` options to match
the current implementation.
This updates the generated option help text so that only the registers
actually supported by AArch64 are listed as `AArch64/RISC-V only`, and
marks `x8`, `x16`, `x17`, `x19`, and `x29`-`x31` as `RISC-V only`.
It also adds a driver test to cover the representative unsupported
AArch64 case for `-ffixed-x8`.
Fixes #186620.
Tests: `build-cir/bin/llvm-lit -sv
clang/test/Driver/aarch64-fixed-x-register.c`
[ObjCARC] Run ObjCARCContract before PreISelIntrinsicLowering (#184149)
74e4694 moved ObjCARCContract from running before the codegen pipeline
into addISelPrepare(), which runs after PreISelIntrinsicLowering.
This broke ObjCARCContract's retainRV-to-claimRV optimization because
ObjCARCContract identifies ARC calls via intrinsics, not their lowered
counterparts.
This patch restores the pre-74e4694 ordering by moving ObjCARCContract
to addISelPasses.
The IntrinsicInst.cpp change looks extraneous but is required here:
ObjCARCContract may now rewrite the bundle operand from retainRV to
claimRV. When PreISelIntrinsicLowering then encounters this new
intrinsic use, lowerObjCCall asserts mayLowerToFunctionCall.
Assisted-by: claude
rdar://137997453
Replace pysnmp with truenas_pysnmp C extension for SNMP traps
Rewrites snmp_trap.py to use the truenas_pysnmp C extension and replaces
the python3-pysnmp4 dependency with python3-truenas-pysnmp.
[libc][docs][NFC] Document cross-compilation testing with QEMU (#188838)
Added a "Building and Testing with an Emulator" section to
full_cross_build.rst using riscv64 and qemu-riscv64 as the example.
Outlined necessary CMake flags for cross-compiling with Clang, including
CMAKE_C_COMPILER_TARGET, CMAKE_CXX_COMPILER_TARGET, and
LLVM_ENABLE_LLD=ON. Switched from CMAKE_SYSROOT to LIBC_KERNEL_HEADERS
and added the gcc-riscv64-linux-gnu package dependency to ensure sysroot
issues on Debian-based systems are avoided while retaining access to
cross-compiler runtime objects.
Explained the self-hosted libc-hermetic-tests target as the required
target for executing tests during a standalone cross build, since the
standard check-libc tests are not hermetic.
Refactored existing CMake examples in full_cross_build.rst to use -S and
-B flags instead of cd and mkdir.
Removed prompt characters from code blocks and separated host
[5 lines not shown]
[flang][OpenMP] Restrict isSafeToParallelize to write-only thread-local effects (#188595)
This is a follow-up fix for commit 0f5e9bee.
Only write effects to thread-local memory should be considered safe to
parallelize in workshare lowering, not reads. When both reads and writes
were safe, the cascading effect in moveToSingle could cause entire
SingleRegions to become fully parallelized, eliminating the omp.single
and its implicit barrier. This removed synchronization points needed to
keep threads coordinated inside sequential loops containing workshared
operations, causing race conditions in forall-workshare patterns.
This was exposed by the Fujitsu Test Suite and made the following tests
regress:
FAIL: test-suite :: Fujitsu/Fortran/0398/Fujitsu-Fortran-0398_0031.test
FAIL: test-suite :: Fujitsu/Fortran/0398/Fujitsu-Fortran-0398_0013.test
FAIL: test-suite :: Fujitsu/Fortran/0398/Fujitsu-Fortran-0398_0030.test
FAIL: test-suite :: Fujitsu/Fortran/0398/Fujitsu-Fortran-0398_0014.test
Updates #143330
[MLIR][AMDGPU] Added l2-prefetch op to AMDGPU (#188457)
This PR adds `global_prefetch` op to prefetch a cache line to high-level
caches using the aligned address of the source `memref` and an offset
provided by the indices of the element containing the cache line. This
provides temporal hints (e.g., regular or high-priority). Note that
out-of-bounds access is allowed in speculative mode. Ensure the source
`memref` is in address space `1`.
---------
Co-authored-by: Krzysztof Drewniak <Krzysztof.Drewniak at amd.com>
[MLIR][Arith] Fix int-range-optimizations miscompile from stale solver state (#188992)
The `--int-range-optimizations` pass runs the `DataFlowSolver` once,
then calls `applyPatternsGreedily` with a `DataFlowListener` that erases
solver state when ops are deleted. However, the greedy driver's
`simplifyRegions` step (which calls `runRegionDCE` between pattern
iterations) can remove block arguments without notifying the listener.
This frees the `BlockArgumentImpl` storage, which may be reused by a
subsequent allocation. The solver then finds stale lattice state keyed
at the reused address and incorrectly treats the new block argument as a
known constant, causing a miscompile.
The existing `enableFolding(false)` was added for the same class of bug
(folding can also remove block arguments). This patch extends the fix by
also disabling region simplification, preventing dead-arg elimination
from causing the same address-reuse problem.
Fixes #137281
Fixes #126195
Assisted-by: Claude Code
[MLIR][SCF] Fix ForLoopRangeFolding miscompile with non-positive MulIOp multiplier (#188995)
The scf-for-loop-range-folding pass transforms loops of the form
for (i = lb; i < ub; i += step) { use(i * c) }
into
for (j = lb*c; j < ub*c; j += step*c) { use(j) }
This transformation is only valid when c is strictly positive, since
scf.for requires a positive step. When c is zero or negative, the new
step becomes zero or effectively negative (wrapping in unsigned
arithmetic for index type), producing an incorrect loop.
Add a guard that restricts the MulIOp folding to cases where the
loop-invariant multiplier is a statically known positive integer
constant. Non-constant loop-invariant multipliers are also excluded
since their sign cannot be determined at compile time.
[4 lines not shown]
mail/claws-mail*: Update 4.3.1 => 4.4.0, remove GTK2 option that use version 3.21.0
Release Notes:
https://lists.claws-mail.org/pipermail/users/2026-March/034710.html
- Remove option GTK2 - GTK2 supported in 3.x only, but 3.x reached EoL.
- Make cosmetic improvements and cleanups.
PR: 293704
Approved by: Chris Hutchinson <portmaster at bsdforge.com> (maintainer)
Co-authored-by: Polarian <polarian at polarian.dev>
Co-authored-by: Chris Hutchinson <portmaster at bsdforge.com>
DEVICE_IDENTIFY.9: Fix function call to detect driver in example code
Fixes: ccabc7c2e556 ("DEVICE_IDENTIFY.9: Modernize description and use cases")
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Replace pysnmp with truenas_pysnmp C extension for SNMP traps
Rewrites snmp_trap.py to use the truenas_pysnmp C extension and replaces
the python3-pysnmp4 dependency with python3-truenas-pysnmp.
[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.
[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.
[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]
[LangRef] Allow monotonic & seq_cst accesses to inter-operate with other accesses
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
```
[18 lines not shown]
[libc][math] Implement C23 half precision erfc function (#180930)
Add support for the half-precision complementary error function
`erfcf16``, using a Sollya generated polynomial implementation with
proper handling of special cases.
Extend the MPFR utilities with erfc support to allow tests.
closes: #180927
Revert "[MLIR] Fix ErasedOpsListener false positives for newly created ops/blocks" (#189010)
Reverts llvm/llvm-project#188956
Hit "merge" by accident on the wrong tab, juggling too may PRs in
parallel...
[SPIR-V] Support for C++ for OpenCL source language (#188791)
- Add CPP_for_OpenCL source language operand
- Handle opencl.cxx.version metadata
Align handling with SPIR-V translator logic and tests presented there
