[X86] Lower `minimum`/`maximum`/`minimumnum`/`maximumnum` using bitwise operations (#170069)
I got somewhat nerd-sniped when looking at a Rust issue and seeing [this
comment about how various min/max operations are compiled on various
architectures](https://github.com/rust-lang/rust/issues/91079#issuecomment-3592393680).
The current `minimum`/`maximum`/`minimumnum`/`maximumnum` code is very
branchy because of the signed-zero handling. Even though we emit select
operations, LLVM *really* prefers to lower them to branches, to the
point of scalarizing vector code to do so, even if `blendv` is
supported. (Should I open a separate issue for that? It seems concerning
that LLVM would rather scalarize a vector operation than emit a couple
`blendv` operations in a row.)
It turns out that handling signed zero operands properly can be done
using a couple bitwise operations, which is branchless and easily
vectorizable, by taking advantage of the following properties:
- When you take the maximum of two floats, the output sign bit will be
the bitwise AND of the input sign bits (since 0 means positive, and the
maximum always prefers the positive number).
[44 lines not shown]
[mlir][linalg] Fix vectorization precondition for tensor.pad (#175869)
This changes `padOp.getLow()` to `padOp.getMixedLowPad()` in
`vectorizePadOpPrecondition()`. The `getMixedLowPad()` function
correctly returns both static and dynamic padding values, ensuring that
the indexing is correct when checking for non-zero low padding on
non-unit result dimensions. Using the added test as an example,
`getLow()` would only return `%low`, which means `en.index()` would be 0
instead of the correct dimension index 1.
---------
Signed-off-by: Ian Wood <ianwood at u.northwestern.edu>
py-icecream: updated to 2.1.9
2.1.9
Removed: Support for Python 3.8.
Fixed: Issues 229 and 60, which means improved lists output.
Big thanks to the community! This release was made possible by the people who contributed to the library.
graphics/drm-66-kmod: fix build with clang 21
With clang 21 graphics/drm-66-kmod fails to compile, with errors similar
to:
In file included from /wrkdirs/usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_9/drivers/gpu/drm/i915/i915_active.c:12:
/wrkdirs/usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_9/drivers/gpu/drm/i915/gt/intel_ring.h:63:2: error: default initialization of an object of type 'typeof (ring->size)' (aka 'const unsigned int') leaves the object uninitialized [-Werror,-Wdefault-const-init-var-unsafe]
63 | typecheck(typeof(ring->size), next);
| ^
/usr/src/sys/compat/linuxkpi/common/include/linux/typecheck.h:31:9: note: expanded from macro 'typecheck'
31 | ({ type __var1; \
| ^
The thread at https://lkml.org/lkml/2025/5/6/1681 appears to imply that
it is safe to suppress the new -Wdefault-const-init-var-unsafe warning.
PR: 292192
Approved by: emaste (maintainer)
MFH: 2026Q1
[2 lines not shown]
py-gcovr: updated to 8.6
8.6
Breaking changes:
Drop support for Python 3.9.
New features and notable changes:
Add support for Python 3.14.
Bug fixes and small improvements:
To avoid merge errors, add the line number to the name of the unknown function.
If intermediate files are kept, rename the gcov files before processing them to log the
final filename.
Use the first line after a function definition and not the first line which is hit.
graphics/drm-66-kmod: fix build with clang 21
With clang 21 graphics/drm-66-kmod fails to compile, with errors similar
to:
In file included from /wrkdirs/usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_9/drivers/gpu/drm/i915/i915_active.c:12:
/wrkdirs/usr/ports/graphics/drm-66-kmod/work/drm-kmod-drm_v6.6.25_9/drivers/gpu/drm/i915/gt/intel_ring.h:63:2: error: default initialization of an object of type 'typeof (ring->size)' (aka 'const unsigned int') leaves the object uninitialized [-Werror,-Wdefault-const-init-var-unsafe]
63 | typecheck(typeof(ring->size), next);
| ^
/usr/src/sys/compat/linuxkpi/common/include/linux/typecheck.h:31:9: note: expanded from macro 'typecheck'
31 | ({ type __var1; \
| ^
The thread at https://lkml.org/lkml/2025/5/6/1681 appears to imply that
it is safe to suppress the new -Wdefault-const-init-var-unsafe warning.
PR: 292192
Approved by: emaste (maintainer)
MFH: 2026Q1
devel/gdb: fix build with clang 21
Compiling devel/gdb with clang 21 results in errors similar to:
/wrkdirs/usr/ports/devel/gdb/work-py311/gdb-15.1/gdb/../gdbsupport/enum-flags.h:97:34: error: non-type template argument is not a constant expression
97 | integer_for_size<sizeof (T), static_cast<bool>(T (-1) < T (0))>::type
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/wrkdirs/usr/ports/devel/gdb/work-py311/gdb-15.1/gdb/../gdbsupport/enum-flags.h:134:20: note: in instantiation of template class 'enum_underlying_type<ui_out_flag>' requested here
134 | typedef typename enum_underlying_type<enum_type>::type underlying_type;
| ^
/wrkdirs/usr/ports/devel/gdb/work-py311/gdb-15.1/gdb/ui-out.h:385:16: note: in instantiation of template class 'enum_flags<ui_out_flag>' requested here
385 | ui_out_flags m_flags;
| ^
/wrkdirs/usr/ports/devel/gdb/work-py311/gdb-15.1/gdb/../gdbsupport/enum-flags.h:97:52: note: integer value -1 is outside the valid range of values [0, 15] for the enumeration type 'ui_out_flag'
97 | integer_for_size<sizeof (T), static_cast<bool>(T (-1) < T (0))>::type
| ^
This is because enum-flags.h does some trickery with casting enum values
to -1 to determine whether the underlying type is signed or not, as part
[13 lines not shown]
devel/gdb: fix build with clang 21
Compiling devel/gdb with clang 21 results in errors similar to:
/wrkdirs/usr/ports/devel/gdb/work-py311/gdb-15.1/gdb/../gdbsupport/enum-flags.h:97:34: error: non-type template argument is not a constant expression
97 | integer_for_size<sizeof (T), static_cast<bool>(T (-1) < T (0))>::type
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/wrkdirs/usr/ports/devel/gdb/work-py311/gdb-15.1/gdb/../gdbsupport/enum-flags.h:134:20: note: in instantiation of template class 'enum_underlying_type<ui_out_flag>' requested here
134 | typedef typename enum_underlying_type<enum_type>::type underlying_type;
| ^
/wrkdirs/usr/ports/devel/gdb/work-py311/gdb-15.1/gdb/ui-out.h:385:16: note: in instantiation of template class 'enum_flags<ui_out_flag>' requested here
385 | ui_out_flags m_flags;
| ^
/wrkdirs/usr/ports/devel/gdb/work-py311/gdb-15.1/gdb/../gdbsupport/enum-flags.h:97:52: note: integer value -1 is outside the valid range of values [0, 15] for the enumeration type 'ui_out_flag'
97 | integer_for_size<sizeof (T), static_cast<bool>(T (-1) < T (0))>::type
| ^
This is because enum-flags.h does some trickery with casting enum values
to -1 to determine whether the underlying type is signed or not, as part
[11 lines not shown]
py-tomlkit: updated to 0.14.0
0.14.0 - 2026-01-13
Changed
- Drop support for Python older than 3.9. Remove 3.8 from the CI matrix.
Added
- Custom encoders can now receive `_parent` and `_sort_keys` parameters to enable proper encoding of nested structures.
- Add `String.type` property to get the string type.
Fixed
- Fixed `tomlkit.boolean()` API to correctly handle boolean inputs.
py-hy: updated to 1.2.0
1.2.0 ("Crackers and Snacks", released 2026-01-14)
Supports Python 3.9 – Python 3.14
New Features
* `setv` now supports chained assignment with `:chain`.
* Several functions in the standard `inspect` module have been
monkey-patched to work better with Hy code: `findsource`,
`getcomments`, `getfile`, `getsource`, `getsourcelines`.
* As a result, the `ll` command in `pdb` should now show a more
useful result in more cases.
net80211: fix arguments to IEEE80211_NOTE in ieee80211_fix_rate
Fix the arguments to the debug statement.
(slightly adjusted from the original submission by bz)
PR: 286448
MFC after: 3 days
net80211: fix arguments to IEEE80211_NOTE in ieee80211_fix_rate
Fix the arguments to the debug statement.
(slightly adjusted from the original submission by bz)
PR: 286448
MFC after: 3 days
[msan] Handle NEON matrix multiplication (integral) (#174510)
Instead of strictly handling smmla/ummla/usmmla, this patch propagates
the shadow, with each output element considered initialized if all its
constituent inputs are fully initialized.
