ng_netflow v9: fix template re-announcement using packet count
Increment fe->sent_packets after export9_send().
Previously, NetFlow v9 templates were only re-announced based on
time, ignoring the packet count parameter (`templ_packets`).
PR: 270083
Reviewed by: glebius pouria
Approved by: glebius (mentor)
MFC after: 1 week
Sponsored by: Subcarpathian BSD User Group
(cherry picked from commit d836dae9f0d888d441234ea11e3cd91614c86aa2)
ValueTracking: Detect cases with no underflow for fadd
In the case where both operands have the same sign,
as long as one of the operands is normal or infinity,
the result cannot underflow to a zero.
Pre-committing for #175614
[MLIR] Support dynamic traits in `DynamicDialect` (#177735)
Unlike Interfaces, Traits in MLIR are static: they are defined via CRTP
templates and used as base classes of an `Op`, which makes them
difficult to attach to an op dynamically.
However, in IRDL and the Python bindings, we define operations
dynamically through `DynamicDialect`, which means the traditional static
traits cannot be applied to them. Traits are important, for example,
they are how MLIR marks an op as a terminator or a non-terminator.
If `DynamicDialect` does not support traits, then even though we can
define an op with regions, we cannot define new terminators or mark an
op as a non-terminator. This makes `DynamicDialect` very limited in
region-related scenarios.
In this PR, we introduce a `DynamicOpTrait` type that “dynamizes”
`OpTrait`, enabling traits to be attached to ops in `DynamicDialect`.
The key design goal is that existing checks in the MLIR codebase such as
[9 lines not shown]
rpki-client: rename pk and opk to cert_pkey and tal_pkey
Additionally swap the argument order in the calls to EVP_PKEY_cmp() since
this looks nicer.
ok claudio job
rpki-client: remove cms_parse_validate_detached()
Geofeed was the only consumer of detache signatures and there are no plans
to support any other content type needing this. So remove this wrapper and
drop the now no longer needed BIO.
Also remove the NULL checks for res and resz in cms_extract_econtent() as
the callers of cms_parse_validate() pass in &cmsz, and cms_parse_validate()
itself passes a &res.
ok claudio job
py-greenlet: updated to 3.3.1
3.3.1 (2026-01-23)
- Publish Windows ARM binary wheels, where available.
- Fix compilation for 3.14t on Windows.
- Publish Windows 3.14t binary wheels for Intel.
- Switch from Appveyor for Windows to Github Actions.
- Fix compilation on MIPS with GCC 15 and binutils 2.45.
- Move most project metadata into the static ``pyproject.toml`` file.
This updates licensing information to use the modern
``License-Expression`` field.
[InstCombine] Combine `select(C0, select(C1, b, a), b)` -> `select(C0&&!C1, a, b)` (#177410)
Fixes #82350
Address cases like:
```
select(C0, select(C1, b, a), b) -> select(C0&!C1, a, b)
select(C0, a, select(C1, b, a)) -> select(C0|!C1, a, b)
```
It seem that it generates better code for the real world examples for
the few targets I have checked: https://godbolt.org/z/KeEMd9b8E .
On the most generic case it generates the same assembly code for the
sources and targets for all targets, expect RISC-V, where the targets
seem shoretr and better (less branching):
https://godbolt.org/z/3has1Td5G So I did not experience any regression
on any target in no scenario.
Proofs: https://alive2.llvm.org/ce/z/DoL3zQ
InstCombine: Fold known-qnan results to a literal nan
Previously we only considered fcNan to fold to qnan for canonicalizing
results, ignoring the simpler case where we know the nan is already
quiet.
[test][NFC] Add more keys to test SDKSettings files (#177538)
Every time DarwinSDKInfo reads a new key out of SDKSettings, a boatload
of test SDKSettings files need to be updated across several repositories
and forks and branches. It’s tedious to be careful to update those with
real values so that the tests are properly regression testing older
SDKs. It’s important to be careful so that the tests are accurate, e.g.
to prevent the scenario where DarwinSDKInfo starts reading a new key out
of SDKSettings and assumes that it’s always available everywhere, when
in reality it was only added a few releases ago and will break with
older SDKs. If the test SDKSettings files continue to be updated ad hoc,
it’s going to be really easy to copy/paste a default value everywhere,
and then clients will see incorrect behaviors with the real SDKs, or
even compiler crashes if the key is unconditionally read. Preemptively
add all of the maybe-possibly-compiler relevant keys to the test
SDKSettings files from the real SDKs so that the test files are an
accurate representation and shouldn't need to be touched in the future.
Where the test SDKSettings have intentionally doctored data, add a
Comments key explaining what is changed from the real SDK, and alter the
SDK name with a tag indicating the change.
