About FPU control word settings in 32-bit environment

[SakiTakamachi]

Description

It was discovered in this issue:
#12076

Here is the sqlite forum conversation:
https://www.sqlite.org/forum/forumpost/abbb95376ec6cd5f

In summary, even in an environment where the CPU can handle extended double-precision floating point numbers, in-line assembly may limit the use of normal double-precision numbers.

Here is the code:

php-src/Zend/zend_float.h

Line 356 in e2189e5

_xpfpa_fpu_cw = (_xpfpa_fpu_oldcw & ~0x100) | 0x200; \

I think it should be fixed, but should this be fixed in a patch version, or should it be in a minor version and accompanied by an RFC?

Thank you.

PHP Version

php8.2.9

Operating System

i386/alpine docker image

[dstogov]

XPFPA_SWITCH_DOUBLE() does exactly what expected - limits the floating point precision to double.

As I understood, the problem occurs because SQLite introduced a faster algorithm that uses long double, but it works incorrectly when precision is limited. (May be I'm wrong).

We can't change this precision because this may cause fragmentation between x86 and other systems. x86_64 uses SSE2 for double that doesn't support long double precision at all.

I suppose we have to use sqlite3_test_control(SQLITE_TESTCTRL_USELONGDOUBLE,0); solution

@iluuu1994 could you please take a look

[SakiTakamachi]

@dstogov

XPFPA_SWITCH_DOUBLE() does exactly what expected - limits the floating point precision to double.

As I understood, the problem occurs because SQLite introduced a faster algorithm that uses long double, but it works incorrectly when precision is limited. (May be I'm wrong).

I am of the same understanding. It seems I didn't convey it well, sorry.

According to the sqlite forum, sqlite3_test_control is explained as follows, so it seems doubtful whether it can be a solution.

The SQLITE_TESTCTRL_USELONGDOUBLE sqlite3_test_control() can be used to change algorithms on-the-fly. But that interface is specifically for testing purposes only. You should not use it in your application. The behavior of that interface is subject to change without notice.

[iluuu1994]

Disclaimer that my knowledge of both IEEE 754 and SQLite is limited. Reading https://www.sqlite.org/forum/forumpost/023baad0fdacea43 it sounds like SQLite does not expect FPU precision to be changed, nor would they like to support it, as they consider it a bug on our side (https://www.sqlite.org/forum/forumpost/abc65bec19475130).

I'm not sure how to fix that, other than 1. not changing the FPU mode which would lead to inconsistent results in PHP, 2. switching back for every call into SQLite.

Also worth noting, they say:

Do I understand correctly that you cannot reproduce the problem without the use of in-line ASM?

But _FPU_SETCW when available does not require in-line assembly. There's also _controlfp_s on Windows and fpsetprec on FreeBSD. So I don't think this requires assembly, the assembly is there as a fallback when these APIs aren't available.

Edit: Also, thank you @SakiTakamachi for your extensive analysis. 🙂

[SakiTakamachi]

Yeah, it seems like the attitude is that they won't accept anything other than the highest precision that the CPU can handle.

I think the only practical way is to temporarily change the precision before and after using the sqlite API.

This is probably the same as idea 2.

[iluuu1994]

@SakiTakamachi Maybe they will reconsider if aware that there is an API on all major platforms? Maybe let them know in the thread you opened. And it would be great if you could verify in your short reproducer.

[SakiTakamachi]

OK, I'll post it in the thread.

[iluuu1994]

@SakiTakamachi Thank you! You should mention _FPU_SETCW on Linux.

[SakiTakamachi]

@iluuu1994
Oops, I've edited.

[SakiTakamachi]

@iluuu1994

Although it is not definitive as the final conclusion has not yet been reached, it appears from the timeline that a fix for this issue has been adopted.

https://sqlite.org/src/timeline?c=aa999d490b743f45&y=a

[iluuu1994]

@SakiTakamachi That's great, thank you! /cc @andypost

[andypost]

Thank you! it means it just need to wait for new sqlite release)

btw I got some reflection of x86 FPU because few tests still fail on x86 (32 bit) https://gitlab.alpinelinux.org/alpine/aports/-/issues/11645#note_104896
The list is https://gitlab.alpinelinux.org/alpine/aports/-/blob/master/community/php82/disabled-tests.x86.list

There was an attempt https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/28340/diffs

[SakiTakamachi]

@andypost
Thank you.

In which php version does the test fail? In some cases, it may be easier to understand by opening a new issue.