Gentoo on old CPUs (e.g. no sse2)

[mmogilvi]

Recently various upstream projects seem to have started assuming SSE2 instructions are available by default on 32 bit x86 processors. This raises a question about the extent to which Gentoo should continue to support such CPUs. If not supported, it seems like it should be officially announced, or at least clearly flagged in relevant ebuilds.

I think most or all pre-SSE2 processors are more than ten years old, and today they are painfully slow for compiling the whole system, even when they work.

Note that AMD athlon processors (circa early 2000s) typically did not support SSE2, although the contemporary Pentium 4 did support it. However, that was one of the few times in history when (ignoring cost and wattage) the fastest single-core AMD performance was often faster than the fastest Intel single-core performance.

Recently I (partially) updated a few old machines that I hadn't updated in several months, and ran into new processor-related problems. A dual-processor Athlon MP machine, a VIA C3 machine ("VIA Ezra"), and a Pentium 4 machine that does have SSE2. Some of these machines also have temperature-related memory issues, manifesting with occasional random "segmentation faults" once every few hours depending on ambient temperature, although I'm filtering those unrepeatable problems out of this post.

The SSE2 processor problems don't particularly surprise me; who is going to regularly test such old/slow systems these days? I don't make any real use of these machines, but I thought I would document my findings here, in case anyone actually cares about similarly old machine:

PROBLEM 1: CHOST vs CHOST_x86

This doesn't actually involve SSE2 specifically:

On my Athlon machine my make.conf has always set CHOST to "i486-pc-linux-gnu", since I first installed gentoo years ago. But this is inconsistent with CHOST_x86 (as reported by the "portageq envvar CHOST_x86" command from https://wiki.gentoo.org/wiki/Changing_the_CHOST_variable ) which is set to "i686-pc-linux-gnu" by default. The above link warns about this possibility when changing CHOST, but I've never actually changed CHOST... The inconsistency hasn't been a problem until recently, when llvm apparently uses CHOST_x86 for installation names of various executables/etc, but clang just uses CHOST, and fails to find llvm stuff because of the inconsistency. (As a tangent, most CPU features seem to be indicated by various CPU feature flags rather than numbers embedded in CHOST i[34567]86. What exactly are the modern guidelines about the distinction between CHOST number vs feature flags?)

WORKAROUND/FIX: Set CHOST_x86 to the same thing as CHOST, and rebuild llvm.

POSSIBLE GENTOO IMPROVEMENTS:

• Maybe CHOST_x86 default should be smarter on ancient systems where CHOST was never i686?
  
• Maybe something should warn about the inconsistency?
  

PROBLEM 2: Qt SSE2 configuration

When built with gcc-6.4.0-r1, the qtcore-5.9.6 package builds the qHash function to require some SSE2 instructions even when I explicitly add the -mno-sse2 option to CFLAGS/CXXFLAGS. This doesn't show up until it tries to build qtwidgets: when it tries to actually use the "uic" it builds early on, uic crashes immediately with an illegal instruction in qtcore's qHash function.

This is somewhat similar to bug 552942, but not exactly. Currently, Qt5 appears to only fully disable SSE2 if the "can I compile SSE2" configure auto-test fails, or it is explicitly disabled on the compile line ("-no-sse", but not via CFLAGS?). It doesn't appear to try to RUN the compiled auto-test program. My guess is that it is supposed to detect SSE2 availability at runtime, but something about the compiler-generated code (inlining related?) is allowing some SSE2 (a movq, at least) into a code path that has not verified the availability of SSE2.

WORKAROUND: Force the "can I compile SSE2" test to intentionally fail by using epatch_user, by adding /etc/portage/patches/dev-qt/qtcore/qt-configure-failSSE2.patch

[krinn]

for #1
This wiki article is horribly written because you cannot get what it is trying to prove, if i clearly get the example taken in it, it shown an old i386 CHOST set on an i686 capable computer, and try to show user howto migrate the i386 into a fully i686 CHOST.
This is a kinda stupid example, i686 is out for years, and users with i3(4-5)86 chost wishing to migrate to i686 could be count on fingers.
Or it could help users that pickup a wrong stage3 file, that wish moving it to a fully i686 CHOST
Not the best example to take for changing CHOST.

#2
The behavior of sse2 set in CFLAGS doesn't control anything outside gcc, by settings sse2 in gcc, you are telling gcc "wherever you could optimize the code to use sse2", there's no check if your cpu handle sse2 or not, just an instruction that tell gcc: do sse2 if you see somewhere that could be change with sse2 code.
This is how gcc has always work, because of cross building or just to build code for another cpu with the feature enable or disable as you wish.

The problem is that it only act on c code, by saying -mno-sse2 you are not saying "do not use sse2", but "do not optimize the c code into sse2 instructions even you see somewhere that could be change to sse2 instructions", and if someone use assembler or inline sse2 instruction, this mean the result will use sse2 even you have tell gcc to not by itself create any.
movq was had with mmx, making a legit usage of movq on a non sse2 cpu, so it would be bad to use movq only if your code cannot be use on a non mmx cpu ; see https://en.wikipedia.org/wiki/X86_instruction_listings#Original_MMX_instructions

To control the optional sse2 within a program, you use CPU_FLAGS_X86 ; however it is the gentoo dev that control if the package have use of CPU_FLAGS_X86 or not ; and if the package could be build with or without sse2.

#3
In case 3, the gentoo dev have properly set CPU_FLAGS_X86 to force sse2, because firefox have announce they will drop building a firefox with an host unable to handle sse2 ; see https://support.mozilla.org/en-US/kb/your-hardware-no-longer-supported
Nothing you could really do except using another browser.

[NeddySeagoon]

krinn,

The CHOST changing guide was written for when glibc dropped i386 support and many users that had installed the i386 stage3 in error needed to change their CHOST, so that they could update glibc. That's ancient history. 64 bit CPUs were just a dream :)

The CHOST sets which CPU the toolchain will run on. It does not affect other things.

C(XX)FLAGS control how C/C++ is compiled. Ebuilds can filter C(XX)FLAGS, so while passing -no-sse2 is the right thing to do, it may never get to the build system.
That will vary by package.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

[Brakio]

Hi,

I'm in a similar situation as mmogilvi.
I have an AMD Athlon XP, and was maintaining a gentoo on it because it is one the only one distributions that do not use SSE2 instructions for some applications, for instance Firefox that was crashing in several other distributions, even if using i686 configuration (because gentoo allows to configure software suited for my PC an to maintain them regularly and not too much difficultly).

Gentoo is well running on that PC (at least as efficiently as a linux on a raspberry-pi, but with more ram, a better video card and a good audio card), and I thought it would be sufficient for my son, for simple internet browsing, and simple tasks like text editing.

But now that (for a few months already) I cannot have up to date browser (Firefox) I'm wondering if I need to get rid of it, even if it still properly works for all the other things....
or just use a frozen Firefox version that will not be maintained anymore....

[Ant P.]

Netsurf is better than Dillo for most uses, and doesn't require SSE2 at all (it's designed primarily for low-end ARM).

[NeddySeagoon]

mmogilvi,

[Brakio]

[Brakio]