On Thu, Jun 27, 2019 at 03:26:32PM +0300, Adrian Bunk wrote: > > We like to support non-sse2 on i386, but we are not comfortable > > fixing webkit2gtk at this stage of the release. > > Why is this relatively small change a problem in a package where new > upstream versions are permitted after the release of stable?
I'll try to explain again with more detail so we all understand the nature of the proposed changes. - WebKitGTK has several mechanisms to run JavaScript code, in brief: a C-based interpreter (CLoop), an assembler-based interpreter and a JIT compiler. - CLoop is the slowest but it is portable and runs in all platforms. It's the one selected at build time when the CPU is unsupported or unknown. - The other two generate CPU-specific code. In an effort to simplify them upstream took recently the decision to stop supporting i386 processors without SSE2 instructions. - Because of that, WebKitGTK 2.24.1 added a build-time check to detect if the compiler can generate SSE2 instructions. For the Debian case I had to add -msse2 -mfpmath=sse to CFLAGS, as suggested by upstream. - The consequence of this is that GCC generates SSE2 instructions when appropriate when compiling regular C/C++ code, causing crashes like the one previously reported. - However, and this is the part that I originally overlooked, only the C-based interpreter is working at the moment in i386. The other two are less actively maintained for i386, and stopped working after some big changes upstream in the last few months. - So it is possible to remove the compile-time check for SSE2 and build the package without those flags in i386. What this all means is that the only real difference between webkit2gtk 2.24.2-1 (in buster) and 2.24.2-2 (in sid) is that, for i386, the former is compiled with -msse2 -mfpmath=sse and the latter is not. So for floating point operations the former uses SSE2 and the latter uses x87. This produces some differences in rounding in some corner cases which could have user-visible consequences. We don't know when it is going to happen, but once upstream brings back JIT support to i386 again we would have to make the decision to either: a) keep using CLoop in order to remain compatible with non-SSE2 CPUs (conservative approach, I'd probably support this one). b) think of a way to support both sets of users so those with more modern processors can benefit from the additional performance of the JIT compiler. This could involve using e.g. /usr/lib/sse2/ for those binaries. I hope this clarifies the situation. Berto