NAS-143453 / 27.0.0-BETA.1 / Give S3 object ownership its own key
permissions_model carried two questions; the second was AWS's
per-bucket S3 Object Ownership setting. It becomes object_ownership,
defaulting to BUCKET_OWNER_ENFORCED, and the model keeps S3 and
MULTIPROTOCOL alone. A MULTIPROTOCOL row folds to OBJECT_WRITER, as
the S3 service does with it.
S3_BUCKET_OWNER_ENFORCED stays spellable and stores as the pair it
always meant. It is undocumented and goes with its last consumer.
test_boto3_roundtrip no longer expects a POSIX refusal on an S3
bucket: that model ignores the filesystem permissions entirely.
api/v27_0_0/s3.py takes the same change as api/v26_0_0/s3.py, the
two being identical here and 26.0 shipping the field.
(cherry picked from commit eb002f0159c3611c0f0854edb231c6d03392b431)
[AMDGPU] Update no-modifier operand tests for the dropped align diagnostic
The no-modifier reg-or-inline operands routed through the HwMode
predicate now report a misaligned tuple as a plain invalid operand,
matching the diagnostic dropped earlier in the stack.
[AMDGPU] Route no-modifier reg-or-inline AsmParser operands through HwMode predicate
Convert the reg-or-inline operands with no modifiers (MFMA VGPR/AGPR
sources, VCSrc, v_pk_mov_b32, VOP scalar f64) from the fixed-class
isRegOrInlineNoMods to the HwMode-aware isRegOrInlineNoModsByHwMode, so an
odd-aligned tuple is rejected at the offending operand column instead of by
the validateVGPRAlign catch-all.
Co-Authored-By: Claude <noreply at anthropic.com>
[AMDGPU] Rename the alignment-aware operand predicates to *Target, NFC
The predicates take a *_AlignTarget/_Target operand, so name them after
it. The HwMode resolution behind the operand's class is an implementation
detail that need not appear in the name.
[AMDGPU] Make custom AsmParser matchers alignment aware
Currently custom matchers accept registers belonging to unaligned classes,
leaving the alignment check and its diagnostic to validateVGPRAlign. The problem
is that validateVGPRAlign does not account for the operand register class, which
may have a different alignment requirement on mixed-alignment targets.
The fix is to make a custom matcher resolve the operand's _AlignTarget class via
HwMode and use that resolved class to accept a register. However, doing so alone
would reject a misaligned register with a generic "invalid operand for
instruction" diagnostic, so extra infrastructure conveys the alignment diagnostic
instead: on a class miss, diagnoseRegAlign re-checks the register against the same
class with alignment relaxed (getUnalignedEquivalentRC, new in AMDGPUBaseInfo);
if it fits, the only problem is alignment, so it records
OperandMatchError::VGPRAlignMismatch on the operand. matchAndEmitInstruction
selects that reason and prints the alignment error, now at the offending operand
column instead of column 1.
This commit converts the input-mods and DP-ALU DPP matchers. The no-modifier
[4 lines not shown]
[AMDGPU] Drop the misaligned VGPR-tuple AsmParser diagnostic
The alignment-aware matchers already reject a misaligned tuple, so a
misaligned operand now fails as a plain invalid operand. Keeping the
dedicated "vgpr tuples must be 64 bit aligned" message only for that
case is not worth the extra match-error ranking, the per-operand
diagnostic, and getUnalignedEquivalentRC, so remove all of it.
[fir][aa] Add opt-in cache for use by fir `AliasAnalysis` clients (#221973)
Adds `AliasAnalysisRecursiveEffectsCache`, an opt-in cache that memoizes
per-operation read/write summaries so that `getModRef` on an operation
with `HasRecursiveMemoryEffects` does not re-walk its nested regions on
every query.
This is independent of the `getSource()` memoization added separately:
that one is keyed on (value, flags) and answers "what memory does this
value refer to", while this one is keyed on the operation and answers
"what does this operation and everything nested in it read and write".
LICM enables both, since it only hoists pure-read ops and so invalidates
neither.
X86: Remove stale EFLAGS live range when converting ADD to LEA
convertToThreeAddress may rewrite an EFLAGS-clobbering ADD into an LEA, which
does not define EFLAGS. hasLiveCondCodeDef guarantees the EFLAGS def was dead, so
drop its LiveIntervals value, otherwise the verifier would fail.
Fixes verifier errors with -early-live-intervals.
Co-authored-by: Claude (Claude-Opus-4.8)
NAS-141885 / 27.0.0-BETA.1 / Depend on websockify explicitly for SPICE display (#19365)
## Problem
VMs with a SPICE display device shell out to the `websockify` binary at
runtime (truenas_pylibvirt's display device runs `websockify --web
/usr/share/spice-html5/ ...` to proxy the console to the web UI). We
never declared that dependency though — websockify only got installed as
a transitive `Recommends:` of `spice-html5`. Once truenas_build disabled
`install_recommends` by default, the `truenas` package started
installing with `--no-install-recommends`, so websockify silently
stopped being pulled in and SPICE consoles broke.
## Solution
Add `websockify` to middlewared's `Depends`. It's a genuine hard runtime
dependency of the SPICE path, so declaring it explicitly makes it come
in regardless of the build's recommends setting and keeps us correct
even if spice-html5's packaging changes.
(cherry picked from commit 44dd41a18e7db2c8466c6fbd72e75be226a9491e)
NAS-141885 / 27.0.0-BETA.1 / Depend on websockify explicitly for SPICE display (#19365)
## Problem
VMs with a SPICE display device shell out to the `websockify` binary at
runtime (truenas_pylibvirt's display device runs `websockify --web
/usr/share/spice-html5/ ...` to proxy the console to the web UI). We
never declared that dependency though — websockify only got installed as
a transitive `Recommends:` of `spice-html5`. Once truenas_build disabled
`install_recommends` by default, the `truenas` package started
installing with `--no-install-recommends`, so websockify silently
stopped being pulled in and SPICE consoles broke.
## Solution
Add `websockify` to middlewared's `Depends`. It's a genuine hard runtime
dependency of the SPICE path, so declaring it explicitly makes it come
in regardless of the build's recommends setting and keeps us correct
even if spice-html5's packaging changes.
(cherry picked from commit 44dd41a18e7db2c8466c6fbd72e75be226a9491e)
[LV] Add tests for argmin/argmax with a narrow index and ptr IVs (NFC) (#222290)
Extend test coverage for argmin/argmax with truncated IVs and pointer
inductions.
sysutils/mirador: update to 1.10.1
v1.10.1
Release Notes
Changed
The notes panel no longer prints its count twice. The border already
carries it, so the row above the list is spent on an active search or
nothing at all — and when it is nothing, the list and the note it is
pointing at get the row. The count returns for the two cases where the
border stops carrying it: an empty panel, where no notes is the only
thing saying the panel is working, and a failed save, where the counter is
spent on unsaved!.
v1.10.0
Release Notes
Fixed
The clock's date was cut without saying so. On a narrow terminal
[47 lines not shown]
[MLIR][XeGPU] Restrict XeGPUPropagateLayout analysis scope (#221793)
This PR prevents concurrent access to traversal and mutation of the
shared IR by restricting the walk scope to determine program order
within each gpu.module.
Previously, although the pass is scoped to a single gpu.module, this
walk climbs all the way up to the enclosing top-level builtin.module and
traverses the entire module — including sibling gpu.modules. When there
is multiple gpu.modules, it causes concurrent traversal and mutation of
the shared IR and eventually leads to a segfault.
Assisted-by: Claude
