[Henryisdjfunkyho]

What

Fix nearbyintf to use MXCSR-controlled rounding and raise FE_INEXACT for measured inexact inputs. Move its rintf implementation to MathExact.cpp, which is compiled with rounding-math semantics, so directed rounding modes and signed zero work correctly. Preserve the NaN path. Tests cover all four MXCSR modes, positive and negative halves, signed zero, and inexact flags. The debt note records the title-libc comparison for nearbyint and the unmeasured nearbyintl behavior.

Tested

Rebased head 472500cb80807684b624df36c2792cf9d2bf9946 onto main 52c09d567d2fa453494dd720fcf53a98149468e4. Windows x86-64, WinLibs GCC 15.2.0, Ninja Release: rebuilt the four focused targets and ran ctest --test-dir build --output-on-failure -R '^(guest_math|guest_math_exact|guest_floating_point|guest_libc_static_imports)$': 4/4 passed, including both tests requested in the latest review. python tools/check_conventions.py --base origin/main and git diff --check origin/main...HEAD passed. Independent review found no actionable rebase issue; it did not run tests. The full build and full-suite results below are from earlier heads, not this rebase.

Earlier validation:

Windows x86-64, WinLibs GCC 15.2.0, Ninja Release, BUILD_TESTING=ON. On head b41c727b01e69f5317294c5084becff862026488, based on main 17f8dfad513b134a4996991109fc9db47a3bb905:

cmake --build build --parallel 8
cmake --build build --target guest_math_tests guest_math_exact_tests guest_floating_point_tests guest_libc_static_imports_tests --parallel 8
ctest --test-dir build --output-on-failure -R '^(guest_math|guest_math_exact|guest_floating_point|guest_libc_static_imports)$'
python tools/check_conventions.py --base origin/main
git diff --check origin/main...HEAD

Full build succeeded; the four requested focused tests passed 4/4 and conventions and diff checks passed. On the preceding rebased head, moving the implementation back to Math.cpp while retaining the new tests made guest_math fail; restoring the fix passed. An independent Luna high review found no actionable issue; exact-input console flag behavior remains unmeasured.

On the preceding base 04fefebe90, ctest --test-dir build --output-on-failure --parallel 8 --timeout 120 reported 18 failures out of 2,837 tests, with skips. Failures were in two AGC tests and 16 VideoOut tests. On the final base, three representative failures (agc_driver_recorder, agc_driver_sample_order_grid_reference, video_out_flip_labels) also failed after replacing both changed math source files with their main versions. VideoOut reported vkGetPhysicalDeviceSurfaceCapabilitiesKHR: Vulkan result -13. This control does not establish the cause of every failure. The full suite was not rerun on the final base.

The earlier overlap scan found only this PR's prior head as a confirmed conflict. Some stale PRs could not be compared automatically; their changed lines were inspected for nearbyint-related changes. No Linux runtime test, new console measurement, title execution, or performance result is claimed for this head. Hosted checks must rerun after the update.

Checklist

• Based on current main; no other open PR implements the same functions
• One topic per PR; follow-ups go in a new PR
• No comments in code except technical debt
• Unimplemented paths throw (NotImplemented_nid_no_patch); silent stubs are listed under Silent stubs in their library's technical debt file
• No notes, investigation .md files or images added to the repository (attach them to this PR)
• New third-party code is a submodule built from source
• Generic behaviour, not specific to one title
• Depends on: none
• Fixes: none
• Unblocks: none
• GPUs tested: n/a
• AI-assisted: yes

[github-actions]

Other open pull requests touch the same code. Merging one will break the other, or both implement the same thing. If this one builds on them, list them in Depends on.

Pull request	Conflicting files (lines on main)	Same exports	Same new files
PR 12605	docs/dev/debt/libc.md L21-24

Some comparisons could not be completed because a pull request conflicts with the base branch. Review these shared files manually before concluding that there is no overlap.

Pull request	Shared files not compared
PR 5021	docs/dev/debt/libc.md
PR 5303	docs/dev/debt/libc.md
PR 6085	core/libs/prx/libc/src/Math.cpp
PR 6295	core/libs/prx/libc/src/Math.cpp core/libs/tests/GuestMath.cpp
PR 7081	docs/dev/debt/libc.md
PR 7386	docs/dev/debt/libc.md
PR 7447	docs/dev/debt/libc.md
PR 7715	docs/dev/debt/libc.md
PR 8150	docs/dev/debt/libc.md
PR 9340	docs/dev/debt/libc.md
PR 9371	docs/dev/debt/libc.md
PR 9447	docs/dev/debt/libc.md
PR 9526	docs/dev/debt/libc.md
PR 9688	docs/dev/debt/libc.md
PR 10226	core/libs/prx/libc/src/Math.cpp core/libs/tests/GuestMath.cpp docs/dev/debt/libc.md
PR 10229	core/libs/prx/libc/src/Math.cpp core/libs/tests/GuestMath.cpp docs/dev/debt/libc.md
PR 10247	core/libs/prx/libc/src/Math.cpp core/libs/tests/GuestMath.cpp docs/dev/debt/libc.md
PR 10317	core/libs/prx/libc/src/Math.cpp core/libs/tests/GuestMath.cpp docs/dev/debt/libc.md
PR 10324	docs/dev/debt/libc.md
PR 10405	docs/dev/debt/libc.md
PR 10620	docs/dev/debt/libc.md
PR 11332	docs/dev/debt/libc.md
PR 11625	docs/dev/debt/libc.md
PR 11724	docs/dev/debt/libc.md
PR 11726	docs/dev/debt/libc.md
PR 12057	docs/dev/debt/libc.md
PR 12292	docs/dev/debt/libc.md
PR 12468	docs/dev/debt/libc.md
PR 12514	docs/dev/debt/libc.md
PR 12560	docs/dev/debt/libc.md
PR 12597	docs/dev/debt/libc.md
PR 12598	docs/dev/debt/libc.md
PR 12627	docs/dev/debt/libc.md
PR 12659	docs/dev/debt/libc.md
PR 12688	docs/dev/debt/libc.md
PR 12700	docs/dev/debt/libc.md
PR 12965	docs/dev/debt/libc.md

[oneandonlydean]

@Henryisdjfunkyho thanks, the change follows the console measurement in the existing nearbyintf debt entry (FE_INEXACT raised for inexact inputs with MXCSR-controlled rounding), and the two-mode test matches it. One small gap: only the float variant was measured on the console. nearbyint and nearbyintl still call the host nearbyint, which does not raise FE_INEXACT, and the existing double test still asserts that (GuestMath.cpp, CheckNearbyint), but no debt entry says those two variants are unmeasured. Please add a short libc debt entry stating that nearbyint and nearbyintl still suppress FE_INEXACT and that the console's behaviour for them is unmeasured (or measure them, as the float variant was).

[B-Howell]

Linux result with a control (the description has Windows only). Linux matters here because FE_INEXACT comes from glibc's nearbyintf there, not UCRT's.

Setup: Ubuntu 22.04 under WSL2, GCC 11.4.0, glibc 2.35, Ninja Release, BUILD_TESTING=ON, AMD Ryzen 7 7800X3D. Head 855113615c9ccfad3158beea300444eb215dd435 merged onto main 09d952f0eb3c68aa3d36713020d60b13644fad02 (clean).

Tests: ctest -R '^guest_math$|^guest_math_exact$|^guest_floating_point$' --repeat until-fail:10

• PR merged onto main: all 3 pass on all 10 runs.
• Control: core/libs/prx/libc/src/Math.cpp restored from main, tests kept: guest_math aborts on the first run, and guest_math_exact and guest_floating_point still pass.

Not tested: guest_libc_static_imports, macOS, the nearbyint/nearbyintl gap raised in the review, any title.

AI-assisted (Claude Code).

[MarcZX10]

I reviewed the implementation and the documentation-only follow-up. The code change uses rintf only for nearbyintf, preserving the existing NaN path, and the added mode-mismatch assertions check both MXCSR-selected results and FE_INEXACT. The debt entry accurately limits the change to the measured float behavior. I independently ran C++20 syntax-only compilation for Math.cpp and GuestMath.cpp, the conventions checker, git diff --check, and a clean merge preview with current main; hosted policy, relinker, specialized checks and Windows build pass. The reported focused runtime tests were run on base cccdaa2734, though.

Before approval, please rebase onto current main (09d952f0eb3c68aa3d36713020d60b13644fad02) and rerun the focused four-test selection on the rebased tree. This branch is 31 commits behind current main; CONTRIBUTING.md requires branches to be based on current main. I found no implementation defect in the reviewed diff. Linux full build is skipped by workflow selection, and no console remeasurement is claimed.

[Henryisdjfunkyho]

@MarcZX10 Rebased onto current main in ff6803b and reran all four requested tests; 4/4 passed. The PR description has the updated results.

[JJenkx]

A comparison against titles' own libc.prx. It finds that this change fixes the flag but returns wrong values in directed rounding modes.

Setup: I built this head ff6803b05a and main (libs only; Windows 11 Enterprise 10.0.22621, WinLibs GCC 15.2.0 UCRT r7, Release). Then I loaded PPSA07923's and PPSA05916's bundled libc.prx natively and called nearbyint, nearbyintf, rint and rintf by NID, side by side with each build. There were 16 inputs (halves, ±0, subnormals, 1e300, 2^52 + 0.5, 2^53, ±inf, NaN) in all four rounding modes set with fesetround, comparing result bits and the raised FE_INEXACT/FE_INVALID. Both titles gave identical results:

differences from the titles	main	this PR
nearbyint	32 (flags only)	32 (flags only, unchanged)
nearbyintf	28 (flags only)	9 (values)
rint, rintf	0	0

The inexact flag is fixed: every round-to-nearest and toward-zero nearbyintf case now matches the titles. In downward and upward modes, however, 9 results are wrong. Before, the values were right and only the flag differed:

FE_DOWNWARD nearbyintf(0.5):    titles +0  (0x00000000)   this PR -0  (0x80000000)
FE_DOWNWARD nearbyintf(+0):     titles +0                 this PR -0
FE_DOWNWARD nearbyintf(-0.5):   titles -1  (0xbf800000)   this PR -0
FE_DOWNWARD nearbyintf(-2.5):   titles -3                 this PR -2
FE_UPWARD   nearbyintf(-0.5):   titles -0                 this PR -1
FE_UPWARD   nearbyintf(-2.5):   titles -2                 this PR -3

Cause: Math.cpp is compiled without -frounding-math. core/libs/prx/libc/CMakeLists.txt:118-119 sets it only for MathExact.cpp, which is why rintf_nid_postfix there matches the titles in every mode. Without it, GCC inlines std::rintf as andps (fabs), add and subtract 2^23, then copysign, a sequence that's only correct when rounding to nearest. The built nearbyintf_nid_postfix disassembles to exactly that. UCRT's own rintf, called through a pointer, is correct in both directed modes here. So moving nearbyintf next to rintf in MathExact.cpp, or returning rintf_nid_postfix(x), should give the titles' values and flag together.

A data point for the debt entry: the titles' nearbyint (double) also raises FE_INEXACT, in all 32 differing cases (e.g. nearbyint(2.5) in each mode), with the same values as main. nearbyintl I didn't test.

AI-assisted: yes (Claude Code).

[MarcZX10]

The new bundled-libc comparison provides a concrete correctness blocker on the current implementation: in Math.cpp, nearbyintf_nid_postfix now calls std::rintf, but the reported GCC build without -frounding-math folds that call into a nearest-mode-only sequence. The exact-head comparison reports wrong result bits in directed modes (including nearbyintf(-0.5f) under FE_DOWNWARD and nearbyintf(-2.5f) under FE_UPWARD), where the previous implementation returned the expected values. The added regression only covers upward x87 with MXCSR nearest and nearest x87 with MXCSR upward; it does not check all four MXCSR rounding modes or negative zero. Please move this implementation to a translation unit compiled with rounding-math semantics (as suggested, alongside the exact math routines) or use another implementation that observes MXCSR reliably, and add directed-mode value plus FE_INEXACT regression coverage. Also, the live main is 3a40945e62; this head is 403 commits behind it (merge base 1829def9bf). After fixing the value regression, please rebase onto current main and rerun the focused math tests there. I’m keeping the changes-requested review in place.

[MarcZX10]

Blocking correctness issue: the current std::rintf call in Math.cpp is compiled without -frounding-math; the exact-head bundled-libc comparison reports wrong results under FE_DOWNWARD/FE_UPWARD, despite fixing FE_INEXACT. Please use an implementation compiled with rounding-mode semantics and add tests for directed modes, signed zero and FE_INEXACT. The tested head is also 403 commits behind live main (3a40945e62), so rebase and rerun focused tests after the fix. Detailed evidence and examples are in my latest comment.

[adriadam10]

Thanks for the change. Blocking issue, confirmed against the tree and the comparison by @JJenkx above:

• core/libs/prx/libc/src/Math.cpp:476: std::rintf here is compiled without -frounding-math (core/libs/prx/libc/CMakeLists.txt:118-120 sets it only for MathExact.cpp), so GCC folds it into a round-to-nearest-only sequence. The FE_INEXACT flag is fixed, but the values are now wrong in the directed modes, where main was right: e.g. FE_DOWNWARD nearbyintf(-0.5f) returns -0 (title libc.prx: -1), FE_UPWARD nearbyintf(-2.5f) returns -3 (title: -2), and nearbyintf(+0) / nearbyintf(0.5f) under FE_DOWNWARD return -0 instead of +0.
  Fix: implement it in a translation unit compiled with -frounding-math (next to rintf_nid_postfix in MathExact.cpp, or return that function's result), keeping the NaN path.
• core/libs/tests/GuestMath.cpp:128-143: the new test only covers x87 upward / MXCSR nearest and the reverse. Please add value plus FE_INEXACT checks for all four MXCSR modes with halves of both signs and ±0, comparing result bits so -0 and +0 are distinguished. It should fail with the current Math.cpp change.
• The head is far behind main; please rebase and rerun the focused math tests after the fix.
• docs/dev/debt/libc.md: the title libc.prx nearbyint (double) also raises FE_INEXACT for inexact inputs (same values as main, per the comparison above); say so in the nearbyint and nearbyintl entry, noting nearbyintl was not compared.

[JJenkx]

A native comparison of this head (b41c727b01, merged onto main 319621ba2e together with #11895) against the nearbyintf of the libc.prx that titles ship. A scratch loader calls the titles' nearbyintf by NID next to this build's on 100,000 random floats, comparing the result bits and the full exception flag set after each call.

	main	this PR
PPSA07923 flags	69,302 differ (titles raise FE_INEXACT, main doesn't)	0
PPSA07923 values	0	0
PPSA05916	same as PPSA07923	same

So the titles' nearbyintf does raise inexact, as this PR says. guest_math and guest_math_exact pass on Windows (WinLibs GCC 15.2.0 UCRT r7, Release).

AI-assisted: yes (Claude Code).

[MarcZX10]

Reviewed — changes requested

The directed-rounding implementation and regression coverage address the earlier code findings, but the tested head is not integrated with the current main changes to the same four files.

What I ran

Reviewed PR head b41c727b01e69f5317294c5084becff862026488, whose merge base with current main is 17f8dfad513b134a4996991109fc9db47a3bb905. Preview-merged it onto current main 3a2b91981651569163768854a1fcdc7193b6667b; the merge is clean, but all four PR-touched paths also changed on current main. Environment: Linux x86-64, Git and GitHub CLI. I did not build or run tests locally.

git fetch https://github.com/boykopovar/AnyPS5.git main:refs/review/main-20261029 refs/pull/12178/head:refs/review/pr-12178-20261029
git merge-base refs/review/main-20261029 refs/review/pr-12178-20261029
git merge-tree --write-tree refs/review/main-20261029 refs/review/pr-12178-20261029
gh api repos/boykopovar/AnyPS5/compare/17f8dfad513b134a4996991109fc9db47a3bb905...3a2b91981651569163768854a1fcdc7193b6667b --jq '.files[].filename'
gh api repos/boykopovar/AnyPS5/pulls/12178/files --paginate --jq '.[].filename'

Results

Check	Result
Current-main merge preview	Pass; clean
Touched paths changed on both sides	Math.cpp, MathExact.cpp, GuestMath.cpp, and docs/dev/debt/libc.md
Focused tests	Author reports guest_math and guest_math_exact pass on the PR head merged onto main 319621ba2e; not rerun here
Local build/tests	Not run

Command output

merge-base: 17f8dfad513b134a4996991109fc9db47a3bb905
git merge-tree --write-tree: 889ead4182337af56f6ae806a10d602e87978d5e
exit=0
changed-path intersection:
core/libs/prx/libc/src/Math.cpp
core/libs/prx/libc/src/MathExact.cpp
core/libs/tests/GuestMath.cpp
docs/dev/debt/libc.md
PR head: b41c727b01e69f5317294c5084becff862026488
current main: 3a2b91981651569163768854a1fcdc7193b6667b

Negative control

Assertion	Change to code under test	Outcome
Directed-rounding regression fails without the fix	None performed by me	Not independently exercised

Findings

Blocking

• The PR is still based on 17f8dfad513b; current main is 3a2b91981651, and current main changed each of the four files this PR edits. The preview merge is clean, but the old-base test report does not validate the integrated current-main tree. The contribution rules require keeping the branch current.

Non-blocking

• The current diff moves nearbyintf to MathExact.cpp and adds bitwise result, signed-zero, four-MXCSR-mode and FE_INEXACT assertions. That addresses the earlier directed-rounding/test-coverage findings; I found no additional code issue in this re-check.

Sources

• Current contribution rules
• PR implementation at the reviewed head
• PR regression tests at the reviewed head

Not verified

• I did not independently build or execute the math tests, test another OS, or run a console comparison. The reported Windows comparison and test results are author-provided.

To get this to a good state

Rebase onto current main and rerun guest_math and guest_math_exact on the new head. Record the exact head and merged base in the Tested section; I will re-check the rebased diff and rerun the focused validation available here.

[Henryisdjfunkyho]

@MarcZX10 Rebased onto main at 52c09d5 and reran the requested math tests on 472500c. Both passed; the PR description has the details.

[MarcZX10]

Reviewed — looks good

The author rebased onto current main, reran the four focused math tests on the exact head, and the directed-rounding fix and regression cases match the reported behavior; I found no blocking issue.

What I ran

• Reviewed exact PR head 472500cb80807684b624df36c2792cf9d2bf9946 against current main 52c09d567d2fa453494dd720fcf53a98149468e4.
• Ran python3 tools/check_conventions.py --base refs/review/main-20261029b and git diff --check refs/review/main-20261029b...refs/review/pr-12178-20261029b locally.
• Inspected the implementation, four-mode positive/negative half-way cases, signed-zero checks, exception-flag assertions, debt text, latest hosted checks, and the author's exact-head test report.

Results

Check	Result
Current-main merge preview	Clean; tree 582cf9ca2652b6b1e87b3f910510f8f5458f713d
Conventions	Passed locally
Diff whitespace	Passed locally
Focused tests on exact head	Author reports guest_math, guest_math_exact, guest_floating_point, and guest_libc_static_imports: 4/4 passed on Windows x86-64 / WinLibs GCC 15.2 Release
Hosted checks	Windows and Ubuntu relinker/ASan and registration-context checks passed; Linux product job skipped; macOS and write-watch jobs were pending when checked

Command output

$ python3 tools/check_conventions.py --base refs/review/main-20261029b
All conventions checks passed.
CONVENTIONS_EXIT:0
$ git diff --check refs/review/main-20261029b...refs/review/pr-12178-20261029b
DIFF_CHECK_EXIT:0
$ git merge-tree --write-tree refs/review/main-20261029b refs/review/pr-12178-20261029b
git merge-tree --write-tree: 582cf9ca2652b6b1e87b3f910510f8f5458f713d
exit=0

The focused-test result above is from the author's report in the PR description, not a local test run by me.

Negative control

• Not rerun on this head. The PR description records a prior negative control: moving the implementation back to Math.cpp while retaining the new tests made guest_math fail; restoring the fix passed.

Findings

Blocking

• None found.

Non-blocking

• The exact-input console flag behavior and Linux runtime behavior remain unmeasured; the description identifies these limits. The current diff is limited to nearbyintf, its focused tests, and the corresponding debt entry.

Sources

• Implementation at reviewed head
• Regression tests at reviewed head
• Debt entry at reviewed head
• Contribution rules at current main

Not verified

• I did not independently run the focused tests, execute a title or console comparison, run Linux product tests, or verify the final result on macOS/write-watch jobs that were still queued.

[JJenkx]

Independent Linux CPU qualification of exact head 472500cb80807684b624df36c2792cf9d2bf9946, with no integration commits or branch changes. Arch Linux7.2.9, Ryzen7950X, GCC16.2.1, Ninja Release; Vulkan hidden.

• Built actual libc and the four requested test targets. guest_math, guest_math_exact, guest_floating_point, guest_libc_static_imports each pass three repetitions: 12 passes, zero skips. Conventions pass against pinned main52c09.
• A CPU-only loader compares the actual unpatched libc library with the existing bundled libc references from PPSA03766 and PPSA07923. **5,760 cases per library:**30 inputs (including signed zeros, subnormals, halves, integral/large values, infinities and both NaN kinds) ×4 MXCSR rounding modes ×4 independently selected x87 modes ×4 DAZ/FTZ settings ×3 sticky-flag seeds. All exceptions masked.
• Both references agree on every recorded field. Candidate result bits, errno, standard C exception flags, x87 flags and control state match both in every case. The clean-main2960 library is a negative control: standard C flags differ on1,792 cases, with no result-bit differences.

**Remaining raw-hardware flag caveat:**384 subnormal cases with DAZ off set MXCSR bit1 (denormal operand) in the candidate, absent in both references. This bit is outside FE_ALL_EXCEPT; main also sets it. Candidate raw SSE flags thus are not fully equivalent even though the standard C flags and returned values are. The local implementation includes floating-point comparisons/arithmetic that can raise that bit. This observation is supplementary to the existing inexact fix, not a new result-bit regression.

This is bundled-library execution on a Linux host, not a fresh console measurement. Unmasked traps, other SDK variants, Windows at this head, GPU/title execution and performance are outside this run.

Probe source, exact pins, source delta, full build/tests and all comparison rows, SHA-256 9a1230d47ecd0586317eb99e418185440d7046c68862f881eab75f6d7e43028d (download verified).

AI-assisted: yes (Codex).

[adriadam10]

Checked the move of nearbyintf to MathExact.cpp (built with -frounding-math), the NaN path, the directed-mode, signed-zero and FE_INEXACT cases in GuestMath.cpp, the debt entries, and the Linux and bundled-libc.prx comparisons from @JJenkx and @MarcZX10; merged.