emerge --info: https://pastebin.com/4REWAv9m lscpu: https://pastebin.com/STyayZVm equery u qtbase: https://pastebin.com/aBLKUMT7 build log: https://pastebin.com/B8BAyfHf similar bug: https://bugs.gentoo.org/898644 packages dev-qt/qtsvg-6.5.1 and dev-qt/qtdeclarative-6.5.1 are affected by this, too. dev-qt/qtsvg-6.5.1 build log: https://pastebin.com/587K3Nq9 dev-qt/qtdeclarative-6.5.1 build log: https://pastebin.com/tbT71bsj When setting -march=x86-64-v2 all 3 packages were emerged fine. Reproducible: Always Steps to Reproduce: 1.Use an old potato AMD machine 2.Try to emerge qtbase Actual Results: emerge fails Gentoo forum discussion: https://forums.gentoo.org/viewtopic.php?p=8792292#8792292
Relevant error message: /var/tmp/portage/dev-qt/qtbase-6.5.1-r1/work/qtbase-everywhere-src-6.5.1_build/include/QtCore/6.5.1/QtCore/private/../../../../../../qtbase-everywhere-src-6.5.1/src/corelib/global/qsimd_p.h:232:8: error: #error "Please enable all x86-64-v3 extensions; you probably want to use -march=haswell or -march=x86-64-v3 instead of -mavx2" dev-qt/qtwayland-6.5.1 and dev-qt/qttools-6.5.1 USE="linguist -assistant -debug -designer -distancefieldgenerator -pixeltool -qattributionsscanner -qdbus -qdiag -qdoc -qplugininfo -test" emerge fine with both -march=native and -march=x86-64-v2
Please attach all of the information rather than using pastebins, as they expire. Thanks.
Created attachment 863747 [details] dev-qt/qtbase-6.5.1-r1 build log
Created attachment 863748 [details] emerge --info
Created attachment 863749 [details] equery u qtbase
Created attachment 863750 [details] dev-qt/qtsvg-6.5.1 build log
Created attachment 863751 [details] dev-qt/qtdeclarative-6.5.1 build log
Created attachment 863752 [details] lscpu
It seems your CPU supports the FMA extension, but not AVX2. This should be reported to Qt upstream.
I'm getting the same issues on an fx-8350. I did wonder if distcc was causing it as the other machine on the network is haswell, but turned off distcc and still get the same errors.
https://bugreports.qt.io/browse/QTBUG-111698 https://bugreports.qt.io/browse/QTBUG-105588 Seem to be upstream bugs.
I am also noticing this problem now with my Intel i7-12800H (attached the /proc/cpuinfo details). I also remembered the problem happening with other packages previously: >>>>> $ cat /etc/portage/package.env ## Firefox fails to compile if built with AVX - disabling www-client/firefox noavx2.conf ## Qt libraries segfault if built with AVX - disabling dev-qt/qtgui noavx2.conf $ cat /etc/portage/env/noavx2.conf CFLAGS="${CFLAGS} -mno-avx2" CXXFLAGS="${CXXFLAGS} -mno-avx2" >>>>> So it seems like it may apply to qtbase now as well.
Created attachment 863869 [details] Intel i7-12800H flags
Similar thread on forums: https://forums.gentoo.org/viewtopic-p-8748367.html
(In reply to Luke A. Guest from comment #11) > https://bugreports.qt.io/browse/QTBUG-111698 > https://bugreports.qt.io/browse/QTBUG-105588 > > Seem to be upstream bugs. These are both closed, however, so it would be much appreciated if someone who is affected could open a new one more specific to their use-case. Thank you!
I have filed the following upstream bug: https://bugreports.qt.io/browse/QTBUG-114719
https://bugreports.qt.io/browse/QTBUG-114719 has been closed as it isn't a QT problem (at least in my case). Apparently, it's a 7-year-old bug in VirtualBox: https://www.virtualbox.org/ticket/15471 I'm not seeing this problem on any of my hosts running Gentoo directly on bare metal.
Also got this on an AMD FX-8350 like Luke A. Guest
Created attachment 865165 [details] build.log qtbase-6.5.1-r1 build.log
Created attachment 865166 [details] environment qtbase-6.5.1-r1 environment
Fails here on AMD FX(tm)-8320 Eight-Core Processor <--- bare metal.
Failing flags on -march=native for Russell: ``` # gcc -march=native -E -v - </dev/null 2>&1 | grep cc1 /usr/libexec/gcc/x86_64-pc-linux-gnu/13/cc1 -E -quiet -v - -march=bdver2 -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mno-avx2 -msse4a -mfma4 -mxop -mfma -mno-avx512f -mbmi -mno-bmi2 -maes -mpclmul -mno-avx512vl -mno-avx512bw -mno-avx512dq -mno-avx512cd -mno-avx512er -mno-avx512pf -mno-avx512vbmi -mno-avx512ifma -mno-avx5124vnniw -mno-avx5124fmaps -mno-avx512vpopcntdq -mno-avx512vbmi2 -mno-gfni -mno-vpclmulqdq -mno-avx512vnni -mno-avx512bitalg -mno-avx512bf16 -mno-avx512vp2intersect -mno-3dnow -mno-adx -mabm -mno-cldemote -mno-clflushopt -mno-clwb -mno-clzero -mcx16 -mno-enqcmd -mf16c -mno-fsgsbase -mfxsr -mno-hle -msahf -mlwp -mlzcnt -mno-movbe -mno-movdir64b -mno-movdiri -mno-mwaitx -mno-pconfig -mno-pku -mno-prefetchwt1 -mprfchw -mno-ptwrite -mno-rdpid -mno-rdrnd -mno-rdseed -mno-rtm -mno-serialize -mno-sgx -mno-sha -mno-shstk -mtbm -mno-tsxldtrk -mno-vaes -mno-waitpkg -mno-wbnoinvd -mxsave -mno-xsavec -mno-xsaveopt -mno-xsaves -mno-amx-tile -mno-amx-int8 -mno-amx-bf16 -mno-uintr -mno-hreset -mno-kl -mno-widekl -mno-avxvnni -mno-avx512fp16 -mno-avxifma -mno-avxvnniint8 -mno-avxneconvert -mno-cmpccxadd -mno-amx-fp16 -mno-prefetchi -mno-raoint -mno-amx-complex --param l1-cache-size=16 --param l1-cache-line-size=64 --param l2-cache-size=2048 -mtune=bdver2 -dumpbase - ``` Can confirm that CXXFLAGS="-march=x86-64-v2" does successfully compile. We'll try and work out _which_ flag it doesn't like.
Please file bug(s) upstream for each combination of flags that fail.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=47709089ee12235f32005aa2295aec843164af16 commit 47709089ee12235f32005aa2295aec843164af16 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-09-02 00:04:21 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-09-05 13:01:11 +0000 qt6-build.eclass: workaround mismatching cpu flags sets qsimd_p.h tries determine if x86-64-v3 or v4 sets supported by the compiler+flags seem complete, and errors out if not. This works out rather badly on Gentoo, even -march=native can fail with some hard. With qsimd_p.h being a private header this only affects dev-qt/* packages, but fwics still need to fix all of dev-qt/* at once given they are going to be using private bits from qtbase. Debated a few options for this: 1. Patch headers (like old fix from bug #898644), but just not setting e.g. __haswell__ is not enough when __AVX2__ still confuses some code. Then unsetting these without going through the compiler leads to left over macros and more confusion. Besides... changing system headers behavior (why is __AVX2__ undef with -mavx2!?) only in distros tend to end in disaster. 2. Detect issues in qtbase ebuild, then disable x86intrin altogether if needed (carries over to other modules) + warn users (aka figure it out yourself). Not really great, users may also end up mismatching flags between dev-qt/ to fix this and then run into issues anyway. 3. Backport the next (wip/unmerged) upstream fix[1] but wait, looks like we are currently still playing whack-a-mole: # if defined(__AVX2__) // List of features present with -march=x86-64-v3 and not architecturally // implied by __AVX2__ # define ARCH_HASWELL_MACROS \ (__AVX2__ && __BMI__ && __BMI2__ && __F16C__ \ && __FMA__ && __LZCNT__ && __POPCNT__) # if ARCH_HASWELL_MACROS == 0 # error "Please enable all x86-64-v3 extensions; <snip> ...so -mno-avx2 -mfma (bug #908420) is fine, older (bug #898644) is too, but if for any reason (VMs, buggy hardware, or the machine without F16C from bug #910419) anything else is disabled, then the issue is still there and may in fact trigger more than before. 4. Similarly to #2, detect issues but in the eclass. Then append -mno-* as needed to flags. Not too bad but passing -mno-* leads us to bug #913400. 5. Based on users flags, pick highest usable -march=x86-64-v* and strip everything else (or strip -march too...). Messy and think users wouldn't be happy about this. It would be what upstream likely wants us to do though, and causes no further problems. Ultimately went with #4 for now, bug #913400 needs fixing either way. - missing from set in #3 += -mno-avx2 (until #3, also -mno-fma) - missing the AVX512* checked in qsimd_h += -mno-avx512* (then let compiler disable features that depend on these) Not great but better than doing nothing, no-op for non-affected users. [1] https://codereview.qt-project.org/c/qt/qtbase/+/498799 Bug: https://bugs.gentoo.org/898644 Bug: https://bugs.gentoo.org/913400 Closes: https://bugs.gentoo.org/908420 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> eclass/qt6-build.eclass | 35 ++++++++++++++++++++++++++++++++++- 1 file changed, 34 insertions(+), 1 deletion(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aa6feab907d063181e5bebeb052c3bd72843449b commit aa6feab907d063181e5bebeb052c3bd72843449b Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-09-02 06:09:58 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-09-05 13:01:11 +0000 dev-qt/qtbase: workaround x86intrin test and feature selection qtbase does a single "big" test for all basic cpu features, and if CXXFLAGS have any matching -mno-* then they will override Qt's flags and the test fails. Surprised by this, Qt aborts unless explicitly disable the feature. Test can be bypassed, but then it does not perform per-flags tests and will fail to build as-is. Like bug #913400, debated a few options: 1. cpu_flags_x86_* to enable each feature, but given this is tied to compiler flags we'd still need to test them to avoid failures and not much better off, not to mention bug #913400 may have added its own -mno-* that go against these. 2. Patching cmake files so it always pass its e.g. -mavx2 after the user's flags (when needed), and does not rely on -march=haswell given that does not override. But fwiw these files do get installed and will alter expected behavior, and handling -march is more annoying. 3. Patch out the bit that makes the x86intrin test prevent building unless explicitly disabled, and let it auto-disable x86intrin entirely if tests fail (subpar for performance if ignored). 4. Do self-tests and disable features that will fail, this has the advantage that revdeps will not try to use these either. 5. One option to bug #913400 was to force simpler flags, which would also solve this. Picked #4 for now, not that particularly like it given it feels like automagic. Hoping will be more temporary than qsimd_p.h workarounds. Better than doing nothing either way, is a no-op for non-affected users. Bug: https://bugs.gentoo.org/908420 Closes: https://bugs.gentoo.org/913400 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> dev-qt/qtbase/qtbase-6.5.2-r1.ebuild | 36 +++++++++++++++++++++++++++++++++++- dev-qt/qtbase/qtbase-6.5.9999.ebuild | 36 +++++++++++++++++++++++++++++++++++- dev-qt/qtbase/qtbase-6.9999.ebuild | 36 +++++++++++++++++++++++++++++++++++- 3 files changed, 105 insertions(+), 3 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d863cc9d8ea3722e0ecd6c17e89d88830b45f4fb commit d863cc9d8ea3722e0ecd6c17e89d88830b45f4fb Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2023-09-13 12:58:55 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2023-09-14 20:39:35 +0000 qt6-build.eclass: skip matching fma in 6.5.3+ Should no longer hard fail if lack AVX2 while have FMA, however it does (still) require to disable AVX2 if lacking anything else for any reason (e.g. broken VMs, oddball hardware, perhaps even users intentionally disabling a feature because they have a problem with it). Generally few users should see their flags modified. Feel the ideal would be for upstream to simply not use features that are disabled rather than error about an incomplete set, or just not use AVX2 if incomplete. Bug: https://bugs.gentoo.org/898644 Bug: https://bugs.gentoo.org/908420 Bug: https://bugs.gentoo.org/913843 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> eclass/qt6-build.eclass | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
