[NFCI][analyzer] Add a clean way to generate nodes (#182377)
Currently the most common way for generating nodes is a complicated and
confusing boilerplate approach, which appears in many places:
- A `NodeBuilderContext` is constructed from a `CoreEngine &` and two
other irrelevant arguments.
- A short-lived temporary `NodeBuilder` is constructed from the
`NodeBuilderContext` and some almost irrelevant node sets.
- `NodeBuilder::generateNode()` is invoked once and accesses the graph
through the `CoreEngine &` to generate the node.
To simplify this, I'm cutting out the wrapper layers and extracting the
"main logic" of the method `NodeBuilder::generateNode()` to a new method
called `CoreEngine::makeNode()`. Eventually I intend to replace most use
of `NodeBuilder`s with direct calls to this method.
To ensure that this new `makeNode()` doesn't generate non-sink nodes
with `PosteriorlyOverconstrained` state, I moved the
`isPosteriorlyOverconstrained()` check from `CoreEngine::generateNode()`
[20 lines not shown]
[X86] add X86DomainReassignmentPass to x86 npm pipeline (#183088)
Seems that the pass has already been ported, but was not hooked into the
npm pipeline
[lldb][Process/FreeBSDKernel] Rename to FreeBSDKernelCore (#182878)
There are two different ways to debug FreeBSD's kernel: core and remote
debugging. Remote debugging is done through `gdb-remote` plugin while
kernel dump and live core debugging is done through `freebsd-kernel`.
The name `freebsd-kernel` is vague for this reason, and following
`elf-core` and `mach-core`'s example, it would be clearer if this plugin
is renamed to `freebsd-kernel-core`.
---------
Signed-off-by: Minsoo Choo <minsoochoo0122 at proton.me>
security/py-cryptography: Fix stage QA errors with py-maturin 1.12.0+
* If built with py-maturin 1.12.0+ following stage QA errors are emitted:
[...]
====> Running Q/A tests (stage-qa)
Error: Python package installs top-level 'docs/' directory in site-packages
Error: Location: lib/python3.11/site-packages/docs
[...]
Error: Python package installs top-level 'tests/' directory in site-packages
Error: Location: lib/python3.11/site-packages/tests
[...]
* This is because older versions of py-maturin didn't install these
stray files due to an bug with the "include" pattern in
"pyproject.toml". With version 1.12.0, these files are now installed.
Approved by: portmgr (build fix blanket)
security/py-cryptography: Convert to PATCH_SITES
liboqs: Update to 0.15.0
upstream changes:
-----------------
0.15.0 [Friday, Nov 14, 2025]
Deprecation notice
* liboqs 0.15.0 is the last version to officially support SPHINCS+. SPHINCS+ will be removed in the 0.16.0 release and replaced by SLH-DSA. liboqs 0.15.0 also removes support for Dilithium.
Significant changes
* Integrated SLH-DSA implementation from pq-code-package/slhdsa-c
o SLH-DSA ACVP tests (#2237)
o Integrate SLH-DSA-C Library (#2175)
* Added NTRU back (#2176)
* Removed all Dilithium implementations (#2275)
* Replaced SPHINCS+ with SLH-DSA for CMake build option OQS_ALGS_ENABLED=STD (#2290)
* Updated CROSS to version 2.2 (#2247)
* Included DeriveEncapsulation functionality (#2221)
* Integrated ML-KEM implementation from ICICLE-PQC (#2216)
Bug fixes
* Fixed erroneously disabled LMS variants with build flag OQS_ENABLE_SIG_STFL_LMS (#2310)
[37 lines not shown]
[SelectionDAG] Add DoNotPoisonEltMask to SimplifyMultipleUseDemandedBits/VectorElts
Add DoNotPoisonEltMask to SimplifyMultipleUseDemandedBits and
SimplifyMultipleUseDemandedVectorElts.
Goal is to reduce amount of regressions after fix of #138513.
[SelectionDAG] Add DoNotPoisonEltMask to SimplifyDemandedVectorEltsForTargetNode
Add DoNotPoisonEltMask to SimplifyDemandedVectorEltsForTargetNode
and try to handle it for a number of X86 opcodes. In some situations
we just fallback and assume that the DoNotPoisonEltMask elements
are demanded.
Goal is to reduce amount of regressions after fix of #138513.
[SelectionDAG] Add DoNotPoisonEltMask to SimplifyDemandedVectorElts
The fix for #138513 resulted in a number of regressions due to
the need to demand elements corresponding to bits used by bitcasts
even if those bits weren't used. Problem was that if we did not
demand those elements the calls to SimplifyDemandedVectorElts
could end up turning those unused elements in to poison, making
the bitcast result poison.
This patch is trying to avoid such regressions by adding a new
element mask ('DoNotPoisonEltMask') to SimplifyDemandedVectorElts
that identify elements that aren't really demanded, but they must
not be made more poisonous during simplifications.
This patch is also fixing a FIXME from commit 6420099bcc62a09e00.
By using the new DoNotPoisonEltMask we no longer need to demand
elements in Op0, that are known to be zero in Op1, when simplifying
AND/MUL. Instead we can request that those elements isn't replaced
by posion, even if we do not care about the exact value.
[VPlan] Fix alias logic in canHoistOrSinkWithNoAliasCheck (#179504)
The correct way to check if two memory locations may alias is outlined
in ScopedNoAliasAAResult::alias: extract this into a helper, to fix the
current logic.
[MLIR][ODS][NVVM] Add EnumAttrIsOneOf/IsNoneOf constraints and use them in NVVM fence ops (#182662)
Add `EnumAttrIsOneOf` and `EnumAttrIsNoneOf` to `EnumAttr.td`, a generic
`AttrConstraint`s that restrict an `EnumAttr` to an allowlist or
denylist
of cases respectively. These are the enum analogs of the existing
`IntIsOneOf` constraint for integer attributes.
`EnumAttrIsOneOf` restricts the attribute to a closed set of permitted
cases. `EnumAttrIsNoneOf` excludes specific cases while allowing all
others, which is more ergonomic when the disallowed set is smaller than
the allowed set and more future-proof when new enum cases are added.
This replaces hand-written verifier logic with ODS-generated
verification, eliminating the `FenceSyncRestrictOp` verifier entirely
and simplifying both `FenceProxyOp` and `FenceProxySyncRestrictOp`
verifiers.
It can also be parameterized through base class hierarchies, allowing
[11 lines not shown]
[MLIR][Linalg][NFC] Simplify tiling canonical pattern (#182909)
Prepare for better composition of canonicalization patterns by splitting
the linalg own canonicalizers from others for particular purposes (ex.
tiling).
Once dialects have their own registration mechanisms, specific passes
can just add more ops/dialects using a yet-to-be-created helper that
would be similar to the existing
`populateLinalgTilingCanonicalizationPatterns`.