| View previous topic :: View next topic |
| Author |
Message |
paddlaren
Tux's lil' helper
Joined: 23 Nov 2005
Posts: 130
Location: Hörby, Sweden
|
 Posted: Sat Oct 19, 2024 9:28 am Post subject: [Solved] Trouble building dev-qt/qtbase with Ryzen 9 9950x |
 |
|
(Title edited to make space for [Solved], original title: Trouble building dev-qt/qtbase with Ryzen 9 9950x CC_FLAGS)
I just got an upgrade from Ryzen9 7950x to 9950x and naturally I enable all flags possible. The upgrade (not empty tree though) wen mostly smooth but there was a strange problem with dev-qt/qtbase
My settings in make.conf was derived from resolve-march-native that reported:
| Code: | | -march=znver4 -mavx512vp2intersect -mavxvnni -mmovdir64b -mmovdiri -mshstk --param=l1-cache-line-size=64 --param=l1-cache-size=48 --param=l2-cache-size=1024 |
Thus COMMON_FLAGS in make.conf was:
| Code: | | CFLAGS="-march=znver4 -mavx512vp2intersect -mavxvnni -mmovdir64b -mmovdiri -mshstk --param=l1-cache-line-size=64 --param=l1-cache-size=48 --param=l2-cache-size=1024 -O2 -pipe" |
(Without the -O2 -pipe media-libs/libvpx-1.14.1 failed to build, which might seem strange as -O2 should be enabled by default from what I read).
GCC is the default:
| Code: | | gcc (Gentoo 13.3.1_p20240614 p17) 13.3.1 20240614 |
When I built dev-qt/qtbase-6.7.2-r5 I got the following strange errors:
| Code: | /usr/bin/x86_64-pc-linux-gnu-g++ -DENABLE_PIXMAN_DRAWHELPERS -DGui_EXPORTS -DMD4C_USE_UTF8 -DQT_ASCII_CAST_WARNINGS -DQT_BUILDING_QT -DQT_BUILD_GUI_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_UP_TO=0x050000 -DQT_EXPLICIT_QFILE_CONSTRUCTION_FROM_PATH -DQT_LEAN_HEADERS=1 -DQT_MOC_COMPAT -DQT_NO_AS_CONST -DQT_NO_CAST_TO_ASCII -DQT_NO_CONTEXTLESS_CONNECT -DQT_NO_DEBUG -DQT_NO_EXCEPTIONS -DQT_NO_FOREACH -DQT_NO_JAVA_STYLE_ITERATORS -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_QEXCHANGE -DQT_NO_USING_NAMESPACE -DQT_QPA_DEFAULT_PLATFORM_NAME=\"xcb\" -DQT_USE_QSTRINGBUILDER -DQT_WARN_DEPRECATED_UP_TO=0x070000 -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2_build/src/gui/Gui_autogen/include -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2_build/include -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2_build/include/QtGui -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/src/gui -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2_build/src/gui -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/src/gui/../3rdparty/VulkanMemoryAllocator -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/src/gui/../3rdparty/D3D12MemoryAllocator -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2_build/include/QtGui/6.7.2 -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2_build/include/QtGui/6.7.2/QtGui -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/src/gui/../3rdparty/md4c -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2_build/include/QtCore -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/mkspecs/linux-g++ -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2_build/src/corelib -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2_build/include/QtCore/6.7.2 -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2_build/include/QtCore/6.7.2/QtCore -I/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2_build/include/QtDBus -isystem /usr/include/harfbuzz -isystem /usr/include/freetype2 -isystem /usr/include/glib-2.0 -isystem /usr/lib64/glib-2.0/include -march=znver4 -mavx512vp2intersect -mavxvnni -mmovdir64b -mmovdiri -mshstk --param=l1-cache-line-size=64 --param=l1-cache-size=48 --param=l2-cache-size=1024 -O2 -pipe -std=c++17 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra -fno-exceptions -fPIC -Wsuggest-override -fcf-protection=full -march=haswell -MD -MT src/gui/CMakeFiles/Gui.dir/painting/qdrawhelper_avx2.cpp.o -MF src/gui/CMakeFiles/Gui.dir/painting/qdrawhelper_avx2.cpp.o.d -o src/gui/CMakeFiles/Gui.dir/painting/qdrawhelper_avx2.cpp.o -c /var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/src/gui/painting/qdrawhelper_avx2.cpp
In file included from /var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2_build/include/QtCore/6.7.2/QtCore/private/qsimd_p.h:1,
from /var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/src/gui/painting/qdrawhelper_p.h:30,
from /var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/src/gui/painting/qdrawhelper_avx2.cpp:5:
/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/src/corelib/global/qsimd_p.h:250:8: error: #error "Please enable all x86-64-v4 extensions; you probably want to use -march=skylake-avx512 or -march=x86-64-v4 instead of -mavx512f"
250 | # error "Please enable all x86-64-v4 extensions; you probably want to use -march=skylake-avx512 or -march=x86-64-v4 instead of -mavx512f"
| ^~~~~
/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/src/corelib/global/qsimd_p.h:247:52: error: ‘__AVX512BW__’ was not declared in this scope
247 | # define ARCH_SKX_MACROS (__AVX512F__ + __AVX512BW__ + __AVX512CD__ + __AVX512DQ__ + __AVX512VL__)
| ^~~~~~~~~~~~
/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/src/corelib/global/qsimd_p.h:252:15: note: in expansion of macro ‘ARCH_SKX_MACROS’
252 | static_assert(ARCH_SKX_MACROS, "Undeclared identifiers indicate which features are missing.");
| ^~~~~~~~~~~~~~~
/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/src/corelib/global/qsimd_p.h:247:67: error: ‘__AVX512CD__’ was not declared in this scope
247 | # define ARCH_SKX_MACROS (__AVX512F__ + __AVX512BW__ + __AVX512CD__ + __AVX512DQ__ + __AVX512VL__)
| ^~~~~~~~~~~~
/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/src/corelib/global/qsimd_p.h:252:15: note: in expansion of macro ‘ARCH_SKX_MACROS’
252 | static_assert(ARCH_SKX_MACROS, "Undeclared identifiers indicate which features are missing.");
| ^~~~~~~~~~~~~~~
/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/src/corelib/global/qsimd_p.h:247:97: error: ‘__AVX512VL__’ was not declared in this scope
247 | # define ARCH_SKX_MACROS (__AVX512F__ + __AVX512BW__ + __AVX512CD__ + __AVX512DQ__ + __AVX512VL__)
| ^~~~~~~~~~~~
/var/tmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2/src/corelib/global/qsimd_p.h:252:15: note: in expansion of macro ‘ARCH_SKX_MACROS’
252 | static_assert(ARCH_SKX_MACROS, "Undeclared identifiers indicate which features are missing.");
| ^~~~~~~~~~~~~~~ |
I had just no idea where to begin so I verified that those requested flags was compatible with my CPU by checking the CPU-flags from lscpu (lscpu | grep -i AVX512F etc) and it was.
So I tried by chanse to add those specifically to the COMMON_FLAGS:
| Code: | | CFLAGS="-march=znver4 -mavx512vp2intersect -mavx512f -mavx512bw -mavx512cd -mavx512dq -mavx512vl -mavxvnni -mmovdir64b -mmovdiri -mshstk --param=l1-cache-line-size=64 --param=l1-cache-size=48 --param=l2-cache-size=1024 -O2 -pipe" |
and qtbase compile just fine.
According to GCC documentation for version 13.3 the problematic flags should be enabled by the -march=znver4:
| Quote: | | AMD Family 19h core based CPUs with x86-64 instruction set support. (This supersets BMI, BMI2, CLWB, F16C, FMA, FSGSBASE, AVX, AVX2, ADCX, RDSEED, MWAITX, SHA, CLZERO, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM, XSAVEC, XSAVES, CLFLUSHOPT, POPCNT, RDPID, WBNOINVD, PKU, VPCLMULQDQ, VAES, AVX512F, AVX512DQ, AVX512IFMA, AVX512CD, AVX512BW, AVX512VL, AVX512BF16, AVX512VBMI, AVX512VBMI2, AVX512VNNI, AVX512BITALG, AVX512VPOPCNTDQ, GFNI and 64-bit instruction set extensions.) |
What is going on here? Why did I need to add those flags specifically? Aren't gcc and macros picking up those flags automatically with -march=znver4?
This problem is new since the CPU upgrade.
BR
Erik
Last edited by paddlaren on Sat Oct 19, 2024 3:55 pm; edited 1 time in total |
|
| Back to top |
|
 |
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2852
|
| Posted: Sat Oct 19, 2024 12:15 pm Post subject: |
|
|
Meh, we already work around a lot of Qt's pickiness in qt6-build.eclass (by forcing e.g. -march=x86-64-v4) but I hadn't thought it could fail that way.
When it compiles e.g. AVX2-using parts (regardless of what cpu people are using at build time, they're picked at runtime if the cpu supports it), it passes -march=haswell to ensure avx2 is enabled which overrides your znver4 (that's fine in itself, this disables avx512 rather than leave "partial" support), but the -mavx512vp2intersect that you pass re-enable avx512 and without the rest.. and so Qt complains that it's incomplete.
Suppose I could do further checks in qt6-build.eclass, albeit all it'll do is force x86-64-v4. At this point we mostly given up trying to get Qt to improve this.
Edit: to observe what happened:
| Code: | Original flags (good on their own, all enabled):
$ gcc -E -march=znver4 -mavx512vp2intersect -mavxvnni -mmovdir64b -mmovdiri -mshstk -x c - <<<"__AVX512F__ __AVX512BW__ __AVX512CD__ __AVX512DQ__ __AVX512VL__" | tail -n 1
1 1 1 1 1
With -march=haswell added (result in incomplete set):
$ gcc -E -march=znver4 -mavx512vp2intersect -mavxvnni -mmovdir64b -mmovdiri -mshstk -march=haswell -x c - <<<"__AVX512F__ __AVX512BW__ __AVX512CD__ __AVX512DQ__ __AVX512VL__" | tail -n 1
1 __AVX512BW__ __AVX512CD__ 1 __AVX512VL__
Like above but without -mavx512vp2intersect (all disabled, which is fine):
$ gcc -E -march=znver4 -mavxvnni -mmovdir64b -mmovdiri -mshstk -march=haswell -x c - <<<"__AVX512F__ __AVX512BW__ __AVX512CD__ __AVX512DQ__ __AVX512VL__" | tail -n 1
__AVX512F__ __AVX512BW__ __AVX512CD__ __AVX512DQ__ __AVX512VL__ |
|
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2852
|
| Posted: Sat Oct 19, 2024 12:38 pm Post subject: |
|
|
Few ways you can work around this anyhow:
1. wait for me to change qt6-build.eclass to force x86-64-v4 with that configuration, if you want your flags to be used it may not be desirable albeit I'd argue x86-64-v4 is good enough and not worth doing your own workarounds over
2. pass the missing -m flags yourself ("-mavx512bw -mavx512cd -mavx512vl", this will enable these even with -march=haswell)
3. drop -mavx512vp2intersect for dev-qt/*:6
4. if care, talk with Qt upstream in my place so this gets improved (probably either by making qsimd_p.h not error out, or trade -march=haswell for -mavx2 and others so it won't introduce "negatives", ideally not by ignoring user *FLAGS entirely), could backport fixes
Edit:
Either way, 1. is now done in https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e91760a3bbc3 and, if solutions 2-3 weren't used, build.log should show:
| Code: | | * C(XX)FLAGS were adjusted due to Qt limitations: -mavxvnni -mmovdir64b -mmovdiri -mshstk --param=l1-cache-line-size=64 --param=l1-cache-size=48 --param=l2-cache-size=1024 -march=x86-64-v4 |
Not perfect (i.e. could keep znver4 and turn it into either #2 or #3), but there's many potential issues and the eclass can't reasonably detect the best *FLAGS for every cases, and impact of enabling a few extra -m over x86-64-v4 should be really minimal and not worth worrying about when the build system or headers are picky.
Haven't actually tried building with the eclass' solution though, I don't have avx512 (still enabled by x86-64-v4) and it causes the build to fail for that reason. |
|
| Back to top |
|
|
Ionen
Developer
Joined: 06 Dec 2018
Posts: 2852
|
| Posted: Sat Oct 19, 2024 2:01 pm Post subject: |
|
|
Overall I'd suggest just using -march=native rather than try to resolve it though, it shouldn't fail that way.
Normally you only need resolve-march-native for cross-compiling or distcc, nevermind if that's actually why. |
|
| Back to top |
|
|
paddlaren
Tux's lil' helper
Joined: 23 Nov 2005
Posts: 130
Location: Hörby, Sweden
|
| Posted: Sat Oct 19, 2024 3:53 pm Post subject: |
|
|
Thanks for the replies, an interesting insight in the qt ebuilds I wasn't aware of. I figure this will be more common as more and more users get the new ryzen CPUs.
I will go with the duplicated CFLAGS for now and I'll see how far it gets me.
If I can find the time I may give the commercial qt sources a go as I have a commercial license (I never use that one for the os or KDE though). Commercial license also include commercial support...
BR
Erik |
|
| Back to top |
|
|
paddlaren
Tux's lil' helper
Joined: 23 Nov 2005
Posts: 130
Location: Hörby, Sweden
|
| Posted: Sat Oct 19, 2024 4:01 pm Post subject: |
|
|
| Quote: | Either way, 1. is now done in https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e91760a3bbc3 and, if solutions 2-3 weren't used, build.log should show:
| Code: | | * C(XX)FLAGS were adjusted due to Qt limitations: -mavxvnni -mmovdir64b -mmovdiri -mshstk --param=l1-cache-line-size=64 --param=l1-cache-size=48 --param=l2-cache-size=1024 -march=x86-64-v4 |
Not perfect (i.e. could keep znver4 and turn it into either #2 or #3), but there's many potential issues and the eclass can't reasonably detect the best *FLAGS for every cases, and impact of enabling a few extra -m over x86-64-v4 should be really minimal and not worth worrying about when the build system or headers are picky.
Haven't actually tried building with the eclass' solution though, I don't have avx512 (still enabled by x86-64-v4) and it causes the build to fail for that reason. |
How can I help testing this? |
|
| Back to top |
|
|
42n4
n00b
Joined: 10 Feb 2015
Posts: 23
|
| Posted: Sat Oct 19, 2024 8:31 pm Post subject: |
|
|
For amd 5950x I use native gcc flags (even plus lto optimizations) and I have no problem with amd native compiled kernel and all programs.
_________________
OS: Gentoo 2.15 gcc13/14
Kernel: Linux 6.11.3-zen1
KDE Plasma 6.2.0
WM: NVIDIA 4060/AMD Wayland
http://bit.ly/gen2ls |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
