sse2 usage for programming languages (#20 part 1.5)
the resolution in #20 (closed) doesn't address a point which is relevant but was not brought up in that issue: what to do with programming language implementations and other packages with observable excess floating-point precision differences. for example, php "guarantees" ieee 754 floating-point support, but we don't provide that on x86-32. there have been several issues filed to this effect, such as aports#11645. fixing this issue for x86-64 simply required not gratuitously setting the fpu control word, but according to @dalias, it is not possible to fully implement standard ieee 754 floats on x86-32 without either sse2 or software emulation. a somewhat similar issue affects rust, which always uses sse2 on x86-32. a freebsd patch exists to get rid of it but of somewhat dubious quality (afaik not actually tested on no-sse2 machines).
this issue is not addressed by the resolution in #20 (closed); based on my interpretation of that, we should compile qt no-sse2, as there are minimal user-facing impacts other than it running slightly slower. however, if we compile php or go or rust without sse2, then all x86-32 users will get observably different floating-point results. if we compile with sse2, then they will not run on no-sse2 cpus, which i guess is not a huge issue for php or go, but may be an issue for rust.