src_configure phase fails when CXXFLAGS contains "-mno-avx512f". When the flag is removed, package can be merged without any problem. Error is ERROR: x86 intrinsics support missing. Check your compiler settings. If this is an error, report at https://bugreports.qt.io with your compiler ID and version, and this output: ${TEST_x86intrin_OUTPUT} CMake Error at cmake/QtBuildInformation.cmake:194 (message): Check the configuration messages for an error that has occurred. Call Stack (most recent call first): cmake/QtBuildInformation.cmake:24 (qt_configure_print_summary) cmake/QtBuildInternals/QtBuildInternalsConfig.cmake:554 (qt_print_feature_summary) CMakeLists.txt:213 (qt_build_repo_end) Reproducible: Always
A large deal of -mno-* will cause this, trying to find a sane solution but not quite sure what I'll do with this yet. Given upstream does runtime detection, they kinda check all cpu features at once in that initial test (that you see failing) -- and use: "-march=cannonlake" "-mrdrnd" "-mrdseed" "-maes" "-msha" "-w" They append this after your flags, so it ends up being "-mno-avx512f" "-march=cannonlake" ... But -march=cannonlake still does not override that, so avx512f is disabled -- and they they try to compile avx512 stuff and it fails. Bypassing that test lets it continue, but it does not perform tests for individual features and then you need -DQT_FEATURE_avx512f=OFF (aka not automated), or else it'll still try to build some avx code, append some -march.. (only for these files that are known to be safe) which won't work with -mno-*. And that's not even the only issue with these. Anyhow, anyone having issues with these should settle for a baseline -march=x86-64-v2 3 4 as fitting for now so don't have to pass -mno-*
(In reply to Ionen Wolkens from comment #1) > A large deal of -mno-* will cause this, trying to find a sane solution but > not quite sure what I'll do with this yet. Given solutions are becoming convoluted, may consider just disabling -DQT_FEATURE_x86intrin with an ewarn if flags have problems, and then let users setup flags for if wanted (or ignore if don't care for a bit more optimizations).
(In reply to Ionen Wolkens from comment #1) > then you need -DQT_FEATURE_avx512f=OFF Might add that cpu_flags_x86_* wouldn't be a magic solution either (albeit somewhat viable), may mismatch with compiler flags (suppose could test each), and other packages are also affected by what's set on qtbase, or if change flags for other packages. And would also need a more flags than are currently supported, current list of features: local features=( avx avx2 avx512{bw,cd,dq,er,f,ifma,pf,vbmi,vbmi2,vl} aesni f16c rdrnd rdseed shani vaes sse2 sse3 sse4_1 sse4_2 ssse3 ) (In reply to Ionen Wolkens from comment #2) > -DQT_FEATURE_x86intrin Guess there's a chance flipping this (or other features) back&forth may break ABI for private components too. Anyhow, just rambling to myself :) Thanks for the report, needed a bug to track this in.
The bug has been closed via 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(-) Additionally, it has been referenced in 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(-)
