Fix sinh() losing precision on 32-bit x86

[marc-mabe]

Problem

On 32-bit x86, sinh() returns results that are off by many ULP compared to other platforms, and that are not correctly rounded:

var_dump(sinh(3));   // i386:  float(10.017874927409904)
                     // other: float(10.017874927409903)
var_dump(sinh(10));  // i386:  float(11013.232874703395)
                     // other: float(11013.232874703393)

Measured against (ex - e-x) / 2 evaluated to 80 decimal digits and rounded to nearest double, over 720 sampled inputs, the i386 result is correctly rounded in only 75 cases (10.4%).

This makes sinh() silently architecture-dependent, so comparisons against precomputed constants fail, cached or serialized values differ between machines, and the error propagates into anything built on sinh().

Cause

init_executor() calls zend_init_fpu(), which clamps the x87 FPU to double precision (a 53-bit mantissa) for the whole request so that PHP's own double arithmetic behaves like IEEE-754 binary64 rather than carrying x87's 64-bit excess precision.

libm's sinh(), however, computes on that same x87 unit and relies on the extended range internally in order to round correctly to double. While the clamp is in place it loses that headroom, so sinh() inside PHP is markedly less accurate than the very same libm sinh() is outside PHP.

Fix

zend_sinh() in Zend/zend_float.h restores extended precision for the duration of the libm call and truncates the result back to double on return, using the XPFPA macros already in that header. PHP_FUNCTION(sinh) calls it.

Wherever XPFPA_HAVE_CW is 0 — x86-64, arm64, and every other target without x87 precision control — zend_sinh() compiles down to a plain sinh() call, so no other platform is affected in behaviour or code generation.

Result on i386, same 720 inputs and same reference:

build	correctly rounded
i386, before	75/720 (10.4%)
i386, after	715/720 (99.3%)

The accuracy figures are stated against a high-precision reference rather than against another platform, because for sinh() no mainstream platform is a correct baseline: glibc on arm64 is itself only correctly rounded for 601/720 (83.5%) of the same inputs. Comparing i386 against arm64 would therefore understate the improvement and mislabel many fixed cases as regressions — against arm64 the change looks like 534 improvements and 26 regressions, whereas against the true value it is 641 improvements and a single regression.

Known limitations

This is a large improvement, not a guarantee. sinh(67) regresses by 1 ULP, because the clamped result there is genuinely the correctly rounded one. It is the only regression in the sample, and the test asserts only inputs that this change fixes.

Tests

ext/standard/tests/math/sinh_fpu_precision.phpt.

All arguments are exact binary fractions and every expected value is the correctly rounded double, written as the shortest decimal that round-trips back to it. Inputs were chosen from the intersection of cases that are wrong on clamped i386, correct on i386 with this change, and correct on x86-64/arm64.

Verified locally with a full make clean + ./configure + make per configuration, on i386 and arm64:

	without fix	with fix
arm64	pass	pass
i386	fail	pass

Relationship to the other XPFPA PRs

This is the same class of bug as the pow()/fpow(), exp() and expm1() fixes and adds a helper to the same part of Zend/zend_float.h.

Notes

• This is the same class of bug as Fix pow(), ** and fpow() losing precision on 32-bit x86 #23578, Fix exp() losing precision on 32-bit x86 #23579 and Fix expm1() losing precision on 32-bit x86 #23581 fix and adds a helper to the same part of Zend/zend_float.h
• This PR is mostly LLM work - I manually verified
• Failing tests of phpt-only commit is visible here https://github.com/php/php-src/actions/runs/33959211724/job/101288014631
• This is the last PR in the road