A Windows conversion now fails when a code entry lies after the first
byte of a guest GS instruction that the TLS builder replaces with UD2.
The new debt entry names both messages, says that no option skips the
checks and that Linux output keeps the instruction, so a user who hits
the refusal knows which target to use.
XNU's poll never reports POLLPRI for out-of-band data, so a guest poll
that asks for it never sees the urgent byte: guest_poll aborts at the
OOB case and a title waiting on priority data would sleep to its
timeout.
On macOS the pending byte is read from SIOCATMARK, which reports it
without consuming it and has no descriptor limit, unlike the fd_set
probe this replaces. POLLRDBAND is set with POLLPRI as FreeBSD 11.4's
sopoll_generic does, and the wait takes the sliced path main already
uses for a kqueue wait, so it wakes on the next slice instead of at the
deadline.
recv(MSG_OOB | MSG_PEEK) was measured to consume the byte on macOS
27.0.1 and kevent with NOTE_OOB does not fire there, which is why the
probe is SIOCATMARK. The select and libSceNet poll paths still miss
urgent data on macOS and are recorded in the debt entry.
On Windows the UCRT drops a write that directly follows a read on an r+,
w+ or a+ stream: fputc and fprintf report success, fwrite returns 0 and
fputs returns EOF, all without the error indicator, and the file is left
unchanged, also after an fflush. On a stream open only for reading, fputc
after a read reports success as well.
Writes now first do what FreeBSD 11.4's __swsetup does: a stream open only
for reading fails with EBADF and sets the error indicator, and an update
stream that is reading drops its read buffer and ungetc data, clears end
of file and writes at the descriptor's offset. This covers fwrite, fputs,
fputc, putc_unlocked, fprintf, fprintf_s, fputwc, fputws, fwprintf,
fwprintf_s, puts and wprintf, and printf, vprintf and printf_s, which
write to standard output through PrintWindows and now return -1 there
instead of throwing.
Linux is unchanged: glibc writes at the stream position, which the libc
technical debt now records.
The 2D-array comparison results were measured with LESSEQUAL only. A
second gfx1036 run over all eight DEPTH_COMPARE_FUNC values (128
kernels) gives the same: a 2D-array address on a 2D T# ignores the
slice, and codes 1 and 56 return 0 under every function. Both entries
now say so.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
A comparison or plain sample with a 2D-array address on a 2D T#
returns what the same sample with a 2D address returns, whatever the
slice, as measured with the hardware oracle on RDNA2 (gfx1036) for
formats 1, 7, 22 and 56 with point and bilinear filtering, while a
four-layer 2D-array T# over the same memory returns a different result
per slice. Codes 1 and 56 also compare to 0 with 2D-array addresses.
The three comparison debt entries keep gfx1013, cube comparisons and
the other formats' array comparisons as open.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Buffer resources and MIMG samplers at register field 26 read s104,
s105, vcc_lo and vcc_hi, as measured with the hardware oracle on RDNA2
(gfx1036) in wave32 and wave64 with raw encodings, which LLVM's
assembler refuses. Loads, format conversion, bounds and stores through
the buffer tuple, and sampling through the sampler tuple, act as the
same words in ordinary SGPRs do, and a change to each of the four
words shows in the result. Both debt entries now keep gfx1013 as open.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Dean