ffmpeg ebuilds would fail if CPU_FLAGS_X86 omits sse2 like CPU_FLAGS_X86="mmx mmxext sse sse3" with The following REQUIRED_USE flag constraints are unsatisfied: cpu_flags_x86_sse3? ( cpu_flags_x86_sse2 ) which looks wrong because sse3 implies sse2 sse support so it should be something like CPU_FLAGS_X86="mmxext sse3" be enough to compile ffmpeg (correct me if I'm wrong) sse3 -> implies (sse2,sse) support (extends sse2) sse2 -> implies (sse) support (extends sse) mmxe -> implies (mmx) support (extends mmx) sse3,sse2, sse co-exists with mmx and mmx3 which are different instruction sets why then this logic: cpu_flags_x86_sse3? ( cpu_flags_x86_sse2 ) cpu_flags_x86_sse2? ( cpu_flags_x86_sse ) cpu_flags_x86_sse? ( cpu_flags_x86_mmxext ) Reproducible: Always
I meant sse3,sse2, sse co-exists with mmx and mmxext question: is it possible at all to support sse3 without supporting sse2 and sse? sse3 = sse2 + extended instructions sse2 = sse + extended instructions mmxext = mmx + extended instructions it's not like sse2 is just extended instructions for sse2 it consists of both https://www.intel.com/content/www/us/en/support/articles/000005779/processors.html
And avx2 implies the CPU has not only sse3 but also ssse3 and aes and almost certainly also sse4_2. By extending the logic of this bug report, the user needs but specify the highest one. Does this have an actual use case? It's also worth reminding that the Gentoo recommendation is to set all supported CPU_FLAGS_* as reported by cpuid2cpuflags with the sensible exception being removing ones that either user does not want (e.g. the so called power-virus) or ones that are supported by the host system but may cause trouble with systems to which the built binaries may be distributed to. Speaking of that, FFmpeg has cpudetection that is very handy for that. ;) Finally, not all ebuilds have sse3 (a rather rare instruction set to see in the wild), so sse2 should be generally set anyway.
(In reply to Niklāvs Koļesņikovs from comment #2) > And avx2 implies the CPU has not only sse3 but also ssse3 and aes and almost > certainly also sse4_2. Yes and it looks like the cpu_flags should only have avx2 in that case CPU_FLAGS_X86 = 'avx2' A portage function like cpu_flags('avx2') could return the full list like 'avx2 sse2, sse, etc). I suggest to transform the CPU_FLAGS_X86 via CPU_FLAGS_X86 = cpu_flags(CPU_FLAGS_X86) first and then the backward compatibility is met. (uniqueness of fags would be provided by cpu_flags function) > By extending the logic of this bug report, the user > needs but specify the highest one. Does this have an actual use case? I've personally seen a few libs in the portage that won't build with both sse2 and sse3 flags set. As to how often that problem occurs - try googling for: "The following REQUIRED_USE flag constraints are unsatisfied: cpu_flags_x86_sse3? ( cpu_flags_x86_sse2 )" > It's also worth reminding that the Gentoo recommendation is to set all > supported CPU_FLAGS_* as reported by cpuid2cpuflags with the sensible > exception being removing ones that either user does not want (e.g. the so > called power-virus) or ones that are supported by the host system but may > cause trouble with systems to which the built binaries may be distributed > to. Speaking of that, FFmpeg has cpudetection that is very handy for that. ;) > > Finally, not all ebuilds have sse3 (a rather rare instruction set to see in > the wild), so sse2 should be generally set anyway. Transforming CPU_FLAGS from make.conf via cpu_flags function before using them should fix the problem like forever. That would give control over the flags to the portage. Less probability for a user to set them wrong. All so that would give an early diagnosis to the wrong set of flags set by a user. The user would from that moment only have to set for example CPU_FLAGS_X86="mmxext sse3" portage would expands that to CPU_FLAGS_X86="mmx mmxext sse sse3 sse3" via cpu_flags functions, the backward compatibility is met for the ebuilds. No logic problems with choosing CPU_FLAGS_X86 from the user side. Still if a user prefers to set CPU_FLAGS_X86="mmx mmxext sse sse3 sse3" he can do it, cpu_flags would just return the same "mmx mmxext sse sse3 sse3" in that case and go on. CPU_FLAGS_X86="sse2" would be transformed by cpu_flags to CPU_FLAGS_X86="sse sse2" I can't think of any case when this wouldn't work. Portage will take care of sse flags, a cool feature.
