The Rosetta conversion limits were measured on an M1 running macOS 15.3.1
and an M5 Max. A survey on an M5 running macOS 26.4 executes ANDN, RDRAND,
the rest of BMI1 and BMI2, LZCNT, PREFETCHW, CLFLUSHOPT, AVX, AVX2, FMA,
F16C and MOVBE while CPUID reports none of them, and raises an illegal
instruction for RDSEED, CLWB, RDPID, ADCX and ADOX.
`Path.write_text(newline=...)` and `zip(strict=True)` were added in
Python 3.10. macOS ships 3.9.6 as /usr/bin/python3, the interpreter CMake
finds when no newer one is installed, so `prepare_release_notes` raised
TypeError when the release workflow wrote its notes and the
`pr_overlap_tools`, `release_package` and `linux_fixed_base` tests failed
on a stock macOS host. Writing the encoded text keeps the newline
translation off on every host, and the dynamic tag counts are compared
before the pairs are walked.
Cult of the Lamb (PPSA06465, #2686) stops at start-up on the first one:
FAIL: unresolved ELF import pXJh3aVk8Ks from libSceContentDelete.prx
Both exports have been on main without an implementation (#2740); the
call itself has not been observed yet.
Orbital (cc408367, tools/ida/db_types.json:541-542) and SharpProspero
(5dfdb4b0, Interop/Content/ContentDelete.cs:25-42) agree on the
signatures: a 64-bit SceContentSearchContentId and a UTF-8 path. The
content library is empty on the host, since libSceContentExport exports
nothing into it, so no id or path can be found. SharpProspero gives only
NoPermission (0x809D5006) and no public source gives the not-found code,
so both calls throw with the id or path named once the null path and the
initialization are checked, like the "not in the host content library"
throws of #3724. sceContentDeleteById moves from
guest_content_unimplemented to the new guest_content_delete test.
NIDs pXJh3aVk8Ks and qC3QW+AltHs match tools/nid_names.py and the shadPS4
aerolib list.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
(cherry picked from commit 928184824a4acdf36a58287034bff8154c861835)
The bundled PSNCore.prx of PPSA06888 calls sceNpTrophy2GetRewardIcon
with (context, handle, reward_id, buffer, size): once with a null buffer
to read the size, then with a buffer of that size. The function still
throws because the reward icon data is unknown.
Co-Authored-By: Claude Haiku 5.5 <noreply@anthropic.com>
v_pk_add/mul/fma/fmac/min/max_f16 threw in f16 denormal modes 0-2. On
RDNA2 (gfx1031) bit 6 clear flushes each denormal input lane to a zero
of its sign, and bit 7 clear flushes an add result below 2^-14 and a
mul or fma result whose exact value rounded to 11 significant bits
with an unbounded exponent is below 2^-14, as the scalar forms do;
min/max flush only their inputs. Packed f16 still throws for f16
rounding other than nearest even.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On RDNA2 (gfx1031) f16/f64 denormal modes 0 and 2 flush the denominator
and numerator of v_div_fixup_f64 to a zero of the same sign and keep a
denormal quotient and result, as v_div_fixup_f32 does with the f32
field. The translation used them unflushed, so 0 / 2^-1074 gave 0
instead of the default NaN.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
v_fma_mix_f32 used its f16 sources unflushed in every mode. On RDNA2
(gfx1031) f16 denormal modes 0 and 2 flush each f16 source to a zero
of its sign, whatever the f32 denormal field, so
v_fma_mix_f32 0, 0, 0x0001 (all f16) is 0 there instead of 2^-24.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
v_fma_f16, v_fmac_f16, v_fmamk_f16 and v_fmaak_f16 ignored the
FLOAT_MODE f16 denormal field. On RDNA2 (gfx1031) at f16 round to
nearest even, bit 6 clear flushes every denormal input to a zero of its
sign, and bit 7 clear flushes the result when the exact product-sum
rounded to 11 significant bits with an unbounded exponent is below
2^-14, the rule v_mul_f16 already follows. The f16 FMA path now flushes
its inputs and its round-to-odd result in those modes; the magnitude
test is shared with float16Binary as flushTinyF16Value.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Both ignored the FLOAT_MODE f16 denormal field. On RDNA2 (gfx1031)
v_cvt_pkrtz_f16_f32 flushes each denormal half result to its signed zero
when bit 7 of FLOAT_MODE is clear, and v_pack_b32_f16 flushes each
denormal half input when bit 6 is clear. Modes that keep them and
shaders without a known float mode are translated as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On RDNA2 (gfx1031) f16 denormal modes 0 and 2 flush the denominator and
numerator of v_div_fixup_f16 to a zero of the same sign and keep a
denormal quotient and result, as v_div_fixup_f32 does with the f32
field. The translation used them unflushed in every mode, so 0x0001 / 0
gave +infinity instead of the default NaN.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
v_cmp_X_f16 and v_cmpx_X_f16 compared denormal halves as their exact
values in every mode. On RDNA2 (gfx1031) f16 denormal modes 0 and 2
flush both inputs to a zero of the same sign first, so
v_cmp_eq_f16 0x0000, 0x0001 is true there. Both inputs now go through
flushF16InputValue; modes 1 and 3 and shaders without a known float
mode are translated as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On AMD's Windows driver 32.0.21045.5002 (RX 6700 XT), a product of two
values the driver knows fit in 16 bits, reduced to 16 bits and stored
with nothing else merged in, keeps all 32 bits of the product.
v_mul_lo_u16 and v_pk_mul_lo_u16 extracted 16-bit factors, so into a
register whose high half was zero they wrote 0xfffe0001 for
0xffff * 0xffff. A factor taken from the low half of its source is now
read as the low 24 bits of the register; the low 16 bits of the product
depend only on the low 16 bits of the factors.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Keep both sides in GuestSysmodule.cpp (the unknown id check and the Windows
unwind region checks) and in libSceSysmodule.md (Silent stubs and Functional).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Dean