summaryrefslogtreecommitdiff
path: root/dev-python/PyQt6
diff options
context:
space:
mode:
authorIonen Wolkens <ionen@gentoo.org>2023-09-01 20:04:21 -0400
committerIonen Wolkens <ionen@gentoo.org>2023-09-05 09:01:11 -0400
commit47709089ee12235f32005aa2295aec843164af16 (patch)
tree3296e30d67f60505b891fec7d3adde3a4a2476e1 /dev-python/PyQt6
parentd1b8e8ef131c26a47369bf8d03f372714a535308 (diff)
downloadgentoo-47709089ee12235f32005aa2295aec843164af16.tar.gz
gentoo-47709089ee12235f32005aa2295aec843164af16.tar.bz2
gentoo-47709089ee12235f32005aa2295aec843164af16.zip
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>
Diffstat (limited to 'dev-python/PyQt6')
0 files changed, 0 insertions, 0 deletions