I wanted to modify my original bug report but it didn't seem possible. Anyway, below is a more accurate example to illustrate the issue. It was copied when running the debugger and stepping through zend_init_fpu() in Zend/zend_float.c:


24	{
(gdb) s
28		if (!EG(saved_fpu_cw_ptr)) {
(gdb) n
29			EG(saved_fpu_cw_ptr) = (void*)&EG(saved_fpu_cw);
(gdb) n
31		XPFPA_STORE_CW(EG(saved_fpu_cw_ptr));
(gdb) n
32	long double n = 1;                                                           
(gdb) n
33	printf("Before %.17Le\n", n/100000);
(gdb) n
Before 1.00000000000000000e-05
35		XPFPA_SWITCH_DOUBLE();
(gdb) n
36	printf("After %.17Le\n", n/100000);
(gdb) n
After 1.00000000000000008e-05
40	}
(gdb)

From a comment in zend_float.h:

| This header file defines several platform-dependent macros that
| ensure equal and deterministic floating point behaviour across
| several platforms, compilers and architectures.

So, apparently, this is done deliberately.  I'm not sure that this
is a good idea, though.

Thanks for getting back to us. Indeed, I suspect so:

/* NOTE: This only sets internal precision. MSVC does NOT support double-
   extended precision! */
# define XPFPA_SWITCH_DOUBLE_EXTENDED()

If I changed the macro XPFPA_SWITCH_DOUBLE() to XPFPA_SWITCH_DOUBLE_EXTENDED(), the problem was resolved in Alpine Linux.

Hence, please investigate further why using XPFPA_SWITCH_DOUBLE() is necessary. On Linux the FPU should be left at 80-bit precision, especially Alpine, as musl libc's strtod() requires it to work properly, not to mention it also breaks any functions that expect the standard ABI on Linux.

Are you interested in this for 32-bit or 64-bit builds?

I think we can safely disable this code if compiling under __SSE__, because we know that PHP itself will not use x87 FPU in that case.

For 32-bit builds targeting x87 FPU, I don't think we want to change this, as we do want normal floating point operations to be based on double precision.

This floating point calculation issue happens in Alpine Linux only, so we are targeting 64-bit builds for Linux only. Thanks for considering!

A possible fix might be <https://github.com/php/php-src/pull/5602>.
Could you please try that, @yitam?

My pleasure! Will get back to you later.

The patch seems to fix the issue after the preliminary round of testing in Alpine Linux with PHP 7.4.5. Congratulations! Please let us know when this patch will be merged to a stable release.

The fix is scheduled to be released with PHP 7.4.7.

The fix had to be reverted due to unforeseen issues on
i386.  PR #5621 is hopefully a better fix.

Thank you all for working hard on fixing this issue. I just tested the new proposed fix but unfortunately it didn't work in Alpine Linux. I added the following 'debugging' lines in zend_float.c:

ZEND_API void zend_init_fpu(void) /* {{{ */                                
{                                                                          
int x = -1;                                                                
#if defined(HAVE__CONTROLFP_S) && !defined(__x86_64__)                     
    x = 1;                                                                 
#elif defined(HAVE__CONTROLFP) && !defined(__x86_64__)                     
    x = 2;                                                                 
#elif defined(HAVE__FPU_SETCW)  && !defined(__x86_64__)                    
    x = 3;                                                                 
#elif defined(HAVE_FPSETPREC)  && !defined(__x86_64__)                     
    x = 4;                                                                 
#elif defined(HAVE_FPU_INLINE_ASM_X86)                                     
    x = 5;                                                                 
#else                                                  
    x = 0;                                             
#endif         


Then I ran the debugger:


Breakpoint 1, zend_init_fpu ()
    at /home/jennyt/php-7.4.6/Zend/zend_float.c:24
24	{
(gdb) s
25	int x = -1;
(gdb) s
36	    x = 5;
(gdb)



Hope this helps!

Thanks for checking, and yes, this was helpful!  I had forgotten
to add the guard to that #elif[1].

[1] <https://github.com/php/php-src/pull/5621/commits/c3fe3f7424b7e9a793ef4b55f197de9e2b6593af>

Note that the fix missed the deadline for PHP 7.4.7, so will have
to wait for PHP 7.4.8 (roughly mid July).

> Note that the fix missed the deadline for PHP 7.4.7, so will have
to wait for PHP 7.4.8 (roughly mid July).

No worries. We will jot it down. A brief testing shows that the new fix works. Thank you all!

The fix is not a fix, or at least not a complete one; it leaves at least 32-bit x86 broken.

If php/zend is really depending on having the fpu in a nonstandard precision mode, some logic to switch in and out of this mode when making external calls is needed; you can't just call external code with a state that violates the ABI that code is expecting.

Also, if you're using the "64-bit" x87 precision mode and assuming it yields behavior equivalent to IEEE double arithmetic, this is not correct. In this mode, computations and x87 registers have a 53-bit significand like IEEE double, but still have a 15-bit exponent like Intel 80-bit extended. This means that you can end up with values which are larger in magnitude than what double can represent, or that have more precision than they should due to being in the denormal range as double but normal with the 15-bit exponent. Such values change in unstable ways when the compiler spills and reloads them, leading to all sorts of catastrophic dangerous bugs. These go back to GCC issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 where many of them are linked, but there are a lot of newer, more specific bug reports as well, including one whereby *integer* code can be transformed incorrectly by the optimizer.

In short, not only is it unsafe to use the nonstandard x87 precision modes; it's also unsafe to do floating point without -fexcess-precision=standard (implied by -std=c* but not by -std=gnu*) on targets with excess precision (32-bit x86 and m68k).

> If php/zend is really depending on having the fpu in a nonstandard precision mode, some logic to switch in and out of this mode when making external calls is needed; you can't just call external code with a state that violates the ABI that code is expecting.

I don't think that's feasible, there are too many external calls. I would expect it to work the other way around, i.e. only switch the precision mode for code segments that need it. I'm not sure what those are, but I expect at least the rounding implementation.

I'd be willing to review a PR in that direction, but given the irrelevance of i386 *without* sse2 as a contemporary architecture, I have no interest in pursuing this myself.