Bug#1077289: gtk4: future test failure in gtk:css / parser math.css caused by i387 FPU

[Simon McVittie]

Source: gtk4
Severity: normal
Tags: experimental
User: debian-qa at lists.debian.org
Usertags: i386

While debugging GTK test failures so we can get 4.14 into unstable, I tried
building the upstream main branch (4.15.x) and running its test suite on
amd64 and i386.

In addition to the same test failures we see on other 32-bit architectures,
there is one genuinely i386-specific test failure when built with Debian's
default toolchain and baseline, in a new test for new features added in the
4.15 branch:

> # Resulting CSS doesn't match reference:
> # --- /home/smcv/src/gtk/testsuite/css/parser/math.ref.css      2024-07-26 21:44:29.837752757 +0000
> # +++ /tmp/.X3GHR2      2024-07-27 13:35:10.407511035 +0000
> # @@ -72,7 +72,7 @@
> #  }
> #
> #  q {
> # -  padding-right: 1.8927892607143719px;
> # +  padding-right: 1.8927892607143721px;
> #  }

I believe this is caused by the 80-bit excess precision of the i387 FPU,
which causes it to get slightly different answers to floating-point
calculations than those that would normally be seen in an IEEE
double-precision environment. The rest of our architectures have IEEE
64-bit double-precision floating point registers, so i386 is really the
outlier here.

A workaround is to build gtk4 with CFLAGS="-ffloat-store" to force
intermediate results to be copied to the stack and truncated to 64-bit
precision. This might have a performance impact, which I have not
benchmarked. If the toolchain team and/or i386 porters (I'm unsure
whose decision it is) are not willing to raise the baseline for i386,
then this is probably the only way to avoid this (other than skipping
the test, which seems unwise), even if it harms performance on CPUs that
are already much slower than is typical.

An alternative is to build gtk4 with SSE2 (CFLAGS="-mfpmath=sse -msse2"),
which would currently be considered to be a baseline violation because
these CPU features are not part of a minimal i686, but might become
allowable or even the default in future if Debian's i386 baseline is
raised to something more recent.

(For example, if i386 becomes officially only intended for use as a
compatibility architecture to run legacy or proprietary i386 binaries on
x86_64 machines via multiarch, then raising its baseline to match x86_64's
baseline would be the obvious choice.)

    smcv