[VPlan][RISCV] Perform a simple version of LSR for EVL tail folded loops
With EVL tail folding the loop step is no longer loop-invariant after vectorization, so SCEV can't analyze it. This prevents LoopStrengthReduce from converting IV-based address calculations to loop-carried phis as before EVL tail folding: https://godbolt.org/z/e3oejca4Y
This adds a *very* simple version of LSR in VPlan that's run for EVL tail folded loops before the step is made unanalyzable by SCEV.
On rva23u64 the following C loop:
for (int i = 0; i < n; i++)
x[i]++;
goes from:
.LBB0_2:
sh2add a3, a1, a0
vsetvli a4, a2, e32, m2, ta, ma
vle32.v v8, (a3)
vadd.vi v8, v8, 1
sub a2, a2, a4
[16 lines not shown]
[flang] Let -fstack-arrays win over CudaHeapAllocPromotion under mem:unified (#218976)
Example:
```fortran
subroutine foo(n)
integer, intent(in) :: n
real :: tmp(n)
```
Compiled with -gpu=mem:unified -fstack-arrays, tmp still ends up in
malloc_unified: CudaHeapAllocPromotion marks the allocation
fir.must_be_heap, which StackArrays then skips, so -fstack-arrays is
silently dropped. Under mem:unified the stack is device accessible, so
the promotion is a placement choice there. Under mem:managed only the
managed allocator is, so it stays a correctness requirement.
Fix: add a stack-arrays option to the pass and skip the promotion when
it is set and the mode is unified.
[CIR] Drop call-conv-lowering opt-out from coro-task.cpp
coro-task.cpp opted out of CallConvLowering because the pass did not handle
parameters of an empty or tag class. CallConvLowering handles them now, so
the test can run the pass and pin what it produces.
complex_co_await has one non-empty value in the modified CHECK lines. We now
lower complex correctly as well.
Assisted-by: Cursor / claude-opus-5
[Offload] Do not do not re-initialize RPC server (#218757)
Summary:
This was done for every executable that was loaded. In the current
OpenMP use this never caused issues, but we need to check if this was
already done so we don't leak the memory.
[GlobalISel] Preserve destination type kind when lowering G_EXTRACT (#218345)
Use the destination LLT kind when selecting the scalar type used to
lower G_EXTRACT. Any-scalar destinations continue using sN, while
specific integer or pointer destinations use iN.
Gap uncovered when adding CSE support for GISel Post-Legalizer combiner.
https://github.com/llvm/llvm-project/pull/217258
Assisted-by: Codex
---------
Signed-off-by: Keshav Vinayak Jha <keshavvinayakjha at gmail.com>
workflows/release-binaries.yml: Only dump the wix logs on failure (#218810)
There is currently a bug in the path on ARM64 Windows, so this step
always fails. Running it after a successful build doesn't make much
sense anyway since since we don't need to see the logs for a good build.
Also, we risk having it fail the whole job even after a successful build
(like what is currently happening on ARM64 Windows), so that's another
reason only to run this when the bulid fails.
[mlir:tblgen] Qualify access to `getContext` to fix #218872. (#218951)
With #218872, some code generated by `tblgen` containing `getContext()`
now uses `OpTyp::getContext()` if that op has a `context` property
instead of the intendend `Operation::getContext()`. This PR qualifies
the access such that the intended function is always called.
Signed-off-by: Ingo Müller <ingomueller at google.com>
Don't drop X509_V_ERR_HOSTNAME_MISMATCH when verify callback returns 1
While not the advised way of using the verify callback (either by OpenSSL
or by us) in production, sometimes folks like to return 1 from everything
in the callback and then check the error return and make decicions about
things.
This fix ensures that such callbacks will see the hostname mismatch and
be able to act upon them.
Reported by Alexander Aleksandrovic Klimov
ok tb@
[AArch64] Remove extra fmov after half-vector Neon LD instruction (#216758)
Currently, after a load instruction resulting in a half-vector tuple,
LLVM emits an extra fmov for explicitly zeroing the upper-half of the
vector register when returning a value in the tuple as the full 128 bit
vector.
This is unneeded as the load instruction already zeros the upper half of
the registers in the tuple.
Add special case to existing peephole function that can recognize the D
sub-reg tuple defining opcode and allow removing the extra FMOV
Full List of Load Instructions Tested:
LD1Twov: 8b, 4h, 2s, 1d
LD1Twov_POST: 8b, 4h, 2s, 1d
LD1Threev: 8b, 4h, 2s, 1d
LD1Threev_POST: 8b, 4h, 2s, 1d
LD1Fourv: 8b, 4h, 2s, 1d
LD1Fourv_POST: 8b, 4h, 2s, 1d
[5 lines not shown]
[MemCpyOpt] Extend call slot optimization for non-dereferenceable destinations. (#217436)
Allow call slot optimization for non-dereferenceable destinations when
execution is guaranteed to reach the store. For this, check if the call
has both willreturn and nounwind attributes, and there are no
instructions between the call and the store that might trap or throw.
Since the store would trap anyway if the destination pointer was not
dereferenceable, we can forward the pointer to the call.
Document alert applicability and the frozen inventory
This commit adds changes to document the applicability axes and the frozen inventory in the alert plugin docs, since the only record of how to regenerate that file lived in the test module's own docstring and you only found it after CI had already failed. The populations are pulled in with automodule so a new one documents itself, and the page spells out what does and does not require a regeneration plus what each guard test means when it fails.
Only report a missing license on HA capable systems
This commit fixes an issue where an unlicensed R-series or Z-series started getting told to contact support about a license it was never sold. Those chassis are appliances so they satisfy the hardware rule, but they cannot fail over, and on 26 the product_type disjunct meant a system with no license only reached this alert when it was HA capable. HA capability is a chassis probe the applicability axes deliberately do not carry, so the test sits in check_sync rather than in applies_to.
Name alert applicability rules and detect black-holed alerts
This commit adds changes to give the alert applicability engine one name per population instead of thirty open-coded rule constructions, and to catch alerts that are created but can never be displayed.
The rules alert declarations gate on now live in a vocabulary module next to the engine, so TRUENAS_HARDWARE is defined once rather than built at eighteen sites in two competing conventions. LicenseRule collapses into EntitlementRule, which asks the entitlement policy about any feature rather than the two the old enum could spell, so STIG and everything after it is a one-line declaration. AllOf joins AnyOf in the algebra, listed_when becomes listed_only_when to say that it narrows, and AlertFacts is gone in favour of the identical EntitlementFacts that applies() was converting to anyway.
A source whose rule is satisfied where its class's rule is not creates alerts that are stored and never shown. Nothing checked for that, and since the failover declarations deliberately straddle the two axes it is no longer something a reviewer can spot by eye. A test now infers the source to class relation out of check() and asserts the implication across every population, with a runtime guard logging the cases static analysis cannot see. It found four pre-existing ones in memory_errors and sensors, which are fixed by narrowing the sources so nothing user visible moves.
One behaviour change worth a release note: failover_related was gating enclosure_status on an HA licence, which is a licensing predicate in front of a hardware question, so unlicensed appliances will now report enclosure faults they were previously silent about. The flag is renamed post_failover_blackout to name what it actually contributes.
Remove the broken SATA DOM wear alert
This commit adds changes to delete the SATA DOM wear alert source and its two classes. The source calls disk.sata_dom_lifetime_left, which was removed in 25.10 and has no implementation anywhere, so it raises on every run on any M or Z series chassis and produces nothing but alert source failures.
Alerts already persisted on existing systems clear on the next start through the stale source check in initialize, which runs before the policies are built, so nothing is announced as cleared. No migration is needed, matching how every previous alert source removal was handled.
Keep uncorrected memory error alerts on Minis
This commit fixes an issue where the uncorrected memory error alert stopped running on Minis even though they carry ECC memory and populate the same EDAC counters the source reads. TRUENAS_HARDWARE excludes MINI by construction, so a licensed Mini lost a proactive support warning it used to get, and any alert it was already sitting on was purged on upgrade without a cleared notification.
TRUENAS_OR_MINI_HARDWARE is the union of the two hardware names, composed from them rather than defined as "not GENERIC" so a hardware class added later has to be added here deliberately. MemorySizeMismatch stays on TRUENAS_HARDWARE because its own check returns early without an HA licence.
Move alert gating onto hardware and license axes
This commit adds changes to give every declaration under alert/source its own applicability rule on the decoupled hardware and license axes, and points the enforcement sites in plugins/alert.py at those rules instead of system.product_type. The products lines stay for now because the API field still reads them. HA classes take a hardware applies_to alongside listed_when on purpose, so on iX hardware whose HA licence is absent or lapsed they leave the settings catalogue without being silenced, and a source that no longer applies now has its stored alerts dropped rather than stranding them undismissable. The two scheduled-reboot classes are the exception: they are gated on the HA licence itself, so a system without one stops seeing them at all.
sata_dom_wear is knowingly shipped in a broken state: its source calls disk.sata_dom_lifetime_left, which was removed in March 2025, so appliances will see the check fail. That is a deliberate, signed-off decision and not an oversight.
The checked-in matrix under pytest/unit/alert/golden spells out old versus new applicability per population for every declaration, and its test regenerates and diffs it so no population change lands unread.
Run the local account expiration alert everywhere
This commit fixes an issue where the local account expiration alert stopped running on Minis even though they can still turn on password aging: max_password_age sits behind the STIG entitlement, whose vector grants on the key column of either hardware side, and that key is injected into every legacy licence. The source is also the admin lockout recovery, since it regenerates shadow a day before the last full admin password ages out, so excluding a system that can arm password aging leaves it with no way back in short of a reboot.
check() already returns early unless max_password_age is set, so that early return is the applicability test and the rule is dropped rather than widened. On a system that cannot set the option the daily cost is one config read.
Say which systems the enclosure alerts newly reach
This commit adds changes to test the failover run gates and to correct what the enclosure change was described as affecting. post_failover_blackout and require_stable_peer move out of the run loop into source_run_gates_pass so both can be checked without a middleware object or a running service, and a frozen inventory test pins which sources carry them and what each one is gated on.
failover_related was gating enclosure_status on an HA licence, which is a licensing predicate in front of a hardware question. Enclosure faults are now reported on every iX appliance that lacks an ENTERPRISE_HA licence, both unlicensed appliances and single controller licensed ones (ENTERPRISE_SINGLE, FREENAS-CERTIFIED). The earlier note said only "unlicensed appliances", which undercounts the fleet by the whole licensed single controller half. EnclosureHealthy is INFO and is raised once per enclosure, expansion shelves included, so affected systems will see several new informational alerts.
The matrix legend claimed a source row meant the source is ran, which was never true: it models applies_to only, and never post_failover_blackout, require_stable_peer, the schedule or source locks. That is the only change to the golden file.
Keep the FIPS misconfiguration alert on licensed Minis and whiteboxes
This commit fixes an issue where the FIPS misconfiguration alert stopped running on licensed Minis and licensed whiteboxes even though those systems can still enable FIPS: the STIG vector is key-only on both hardware sides and STIG is injected into every legacy licence, so they are entitled while TRUENAS_HARDWARE excluded them by construction.
EXPECTED_TO_BE_LICENSED is a strict superset of both the old product_type gate and the hardware gate, so nothing loses coverage, unlicensed appliances keep the check that catches FIPS being active when it was never configured, and licensed whiteboxes that could never see this alert are now covered too.
