Created attachment 882627 [details] build.log For a little context, my CPU claims to support rdrnd and rdseed but it actually doesn't. I get this in dmesg at boot: [ 0.000000] RDRAND is not reliable on this platform; disabling. And the build stops with this: WARNING: CPU random generator seem to be failing, disabling hardware random number generation WARNING: RDRND generated: 0xffffffff 0xffffffff 0xffffffff 0xffffffff Incompatible processor. This Qt build requires the following features: rdrnd rdseed # cat /proc/cpuinfo processor : 0 vendor_id : AuthenticAMD cpu family : 23 model : 113 model name : AMD Ryzen 7 3700X 8-Core Processor stepping : 0 microcode : 0x8701013 cpu MHz : 2939.269 cache size : 512 KB physical id : 0 siblings : 16 core id : 0 cpu cores : 8 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 16 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov succor smca sev sev_es bugs : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass retbleed smt_rsb srso bogomips : 7203.27 TLB size : 3072 4K pages clflush size : 64 cache_alignment : 64 address sizes : 43 bits physical, 48 bits virtual power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14] # 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=znver2 -mmmx -mpopcnt -msse -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -mavx -mavx2 -msse4a -mno-fma4 -mno-xop -mfma -mno-avx512f -mbmi -mbmi2 -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 -madx -mabm -mno-cldemote -mclflushopt -mclwb -mclzero -mcx16 -mno-enqcmd -mf16c -mfsgsbase -mfxsr -mno-hle -msahf -mno-lwp -mlzcnt -mmovbe -mno-movdir64b -mno-movdiri -mmwaitx -mno-pconfig -mno-pku -mno-prefetchwt1 -mprfchw -mno-ptwrite -mrdpid -mrdrnd -mrdseed -mno-rtm -mno-serialize -mno-sgx -msha -mno-shstk -mno-tbm -mno-tsxldtrk -mno-vaes -mno-waitpkg -mwbnoinvd -mxsave -mxsavec -mxsaveopt -mxsaves -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=32 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=znver2 -dumpbase - # emerge --info '=dev-qt/qtbase-6.6.1-r3::gentoo' Portage 3.0.61 (python 3.11.7-final-0, default/linux/amd64/17.1, gcc-13, glibc-2.38-r9, 6.1.67-gentoo-clang-r1 x86_64) ================================================================= System Settings ================================================================= System uname: Linux-6.1.67-gentoo-clang-r1-x86_64-AMD_Ryzen_7_3700X_8-Core_Processor-with-glibc2.38 KiB Mem: 32830576 total, 6089604 free KiB Swap: 50331644 total, 49514744 free sh bash 5.2_p26 ld GNU ld (Gentoo 2.41 p4) 2.41.0 app-misc/pax-utils: 1.3.7::gentoo app-shells/bash: 5.2_p26::gentoo dev-build/autoconf: 2.72-r1::gentoo dev-build/automake: 1.16.5-r1::gentoo dev-build/cmake: 3.28.1-r1::gentoo dev-build/libtool: 2.4.7-r2::gentoo dev-build/make: 4.4.1-r1::gentoo dev-build/meson: 1.3.1-r1::gentoo dev-lang/perl: 5.38.2-r1::gentoo dev-lang/python: 3.11.7::gentoo, 3.12.1_p1::gentoo sys-apps/baselayout: 2.14-r1::gentoo sys-apps/openrc: 0.53::gentoo sys-apps/sandbox: 2.38::gentoo sys-devel/binutils: 2.41-r4::gentoo sys-devel/binutils-config: 5.5::gentoo sys-devel/gcc: 13.2.1_p20240113-r1::gentoo sys-devel/gcc-config: 2.11::gentoo sys-kernel/linux-headers: 6.6::gentoo (virtual/os-headers) sys-libs/glibc: 2.38-r9::gentoo Repositories: gentoo location: /var/db/repos/gentoo sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 volatile: True sync-rsync-verify-metamanifest: yes sync-rsync-verify-jobs: 1 sync-rsync-extra-opts: sync-rsync-verify-max-age: 24 ACCEPT_KEYWORDS="amd64 ~amd64" ACCEPT_LICENSE="@FREE" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe -frecord-gcc-switches -frecord-gcc-switches" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=native -pipe -frecord-gcc-switches -frecord-gcc-switches" DISTDIR="/var/cache/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH MAIL PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT WINEPREFIX XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME root" FCFLAGS="-O2 -march=native -pipe -frecord-gcc-switches -frecord-gcc-switches" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance buildpkg buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox pkgdir-index-trusted preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -march=native -pipe -frecord-gcc-switches -frecord-gcc-switches" GENTOO_MIRRORS="http://gentoo.mirror.web4u.cz/ http://tux.rainside.sk/gentoo/ http://ftp.belnet.be/pub/rsync.gentoo.org/gentoo/ https://mirrors.ircam.fr/pub/gentoo-distfiles/" LANG="C" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0" LEX="flex" MAKEOPTS="-j8" PKGDIR="/var/cache/binpkgs" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--exclude=* --dry-run" PORTAGE_TMPDIR="/var/tmp" SHELL="/bin/bash" USE="X acl amd64 bzip2 cli crypt dri fortran gdbm iconv ipv6 libtirpc multilib ncurses nls opengl openmp pam pcre qml readline seccomp split-usr ssl test-rust unicode xattr zlib" ABI_X86="64" ADA_TARGET="gnat_2021" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_anon authn_dbm authn_file authz_dbm authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir env expires ext_filter file_cache filter headers include info log_config logio mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx mmxext sse sse2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 ntrip navcom oceanserver oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 tsip tripmate tnt ublox" INPUT_DEVICES="libinput" KERNEL="linux" LCD_DEVICES="bayrad cfontz glk hd44780 lb216 lcdm001 mtxorb text" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php8-1" POSTGRES_TARGETS="postgres15" PYTHON_SINGLE_TARGET="python3_11" PYTHON_TARGETS="python3_11" RUBY_TARGETS="ruby31" VIDEO_CARDS="amdgpu fbdev intel nouveau radeon radeonsi vesa dummy" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipp2p iface geoip fuzzy condition tarpit sysrq proto logmark ipmark dhcpmac delude chaos account" Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LC_ALL, LD, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PYTHONPATH, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS # emerge -pqv '=dev-qt/qtbase-6.6.1-r3::gentoo' [ebuild N ] dev-qt/qtbase-6.6.1-r3 USE="X concurrent dbus gui libinput network nls opengl sql sqlite ssl udev widgets xml -accessibility -brotli -cups -eglfs -evdev -gles2-only -gssapi -gtk -icu -libproxy -mysql -oci8 -odbc -postgres -sctp -test -tslib -vulkan -wayland -zstd" [ebuild N ] dev-qt/qtshadertools-6.6.1 USE="-test" [ebuild N ] dev-qt/qtdeclarative-6.6.1 USE="opengl sql widgets -test -vulkan" [ebuild N ] dev-qt/qttools-6.6.1 USE="assistant linguist opengl qml widgets -clang -designer -distancefieldgenerator -gles2-only -pixeltool -qdbus -qdoc -qtattributionsscanner -qtdiag -qtplugininfo -test -vulkan -zstd" [ebuild N ] dev-qt/qttranslations-6.6.1 It builds ok if I add '-mno-rdrnd -mno-rdseed' after '-march=native' in CFLAGS.
I don't think there's much I can do here if compiler reports rdrnd support with =native (-mrdrnd -mrdseed is there), *could* add a bunch of CPU_FLAGS_X86 as an alternative but I'd rather not go there. Think you should just explicitly keep turning it off in *FLAGS if it's not usable. Sounds like it'd be generally safer too.
(not to say I may not revisit this, Qt been a massive annoyance with these)
(In reply to Ionen Wolkens from comment #2) > (not to say I may not revisit this, Qt been a massive annoyance with these) Well, maybe I could make an exception for at least rdrnd+seed rather than add the whole wall of CPU_FLAGS_X86 (and add more as needed). Need to check how Qt behaves.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c198f69e66547b5ba7d2ba1b9bae576ce93ee703 commit c198f69e66547b5ba7d2ba1b9bae576ce93ee703 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2024-01-19 21:07:22 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2024-01-19 22:12:37 +0000 dev-qt/qtbase: add IUSE=cpu_flags_x86_rdrand Hopefully this is enough to (actually) fix bug #922498, doing -mno-rdrnd had a similar effect of passing QT_FEATURE_rdrnd=OFF (but don't have a cpu to test behavior with just -march=native). Maybe will extend this at some point, but let's treat this one as as a special case given not the first I've seen of this with rdrand. For anyone with rdrand issues, obviously do not enable this. Probably not worth a revbump considering issue is at build time, seems safe and could save a few rebuilds. fwiw also won't fail in case of an aberrant rdrand being set combined with -mno-rdrnd. Closes: https://bugs.gentoo.org/922498 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> dev-qt/qtbase/qtbase-6.6.1-r3.ebuild | 11 ++++++++++- dev-qt/qtbase/qtbase-6.6.9999.ebuild | 11 ++++++++++- dev-qt/qtbase/qtbase-6.7.9999.ebuild | 11 ++++++++++- dev-qt/qtbase/qtbase-6.9999.ebuild | 11 ++++++++++- 4 files changed, 40 insertions(+), 4 deletions(-)
At least net-im/telegram-desktop does not build and run (sigsegv) with dev-qt/qtbase-6.6.1-r3:6/6.6.1::gentoo CPU_FLAGS_X86="-rdrand" make.conf: COMMON_FLAGS="-march=x86-64-v3 -mtune=generic -O2 -pipe" CFLAGS="${COMMON_FLAGS}" CXXFLAGS="${COMMON_FLAGS}" FCFLAGS="${COMMON_FLAGS}" FFLAGS="${COMMON_FLAGS}" $ cat /proc/cpuinfo | grep model | head -2 model : 167 model name : 11th Gen Intel(R) Core(TM) i5-11500 @ 2.70GHz
Can reproduce, albeit need to look into this a bit more before deciding what to do. My "guess" would be that this only broken when the processor actually supports rdrand and runtime detection does something wrong when it sees support. And I don't see anything wrong with disabling the USE even if the processor *does* support it (e.g. binhosts), so... may end up reverting the USE addition if I can't find a better option.
Created attachment 882985 [details] telegram-desktop gdb backtrace.txt Not planning to really debug this, but attaching backtrace in case anyone wants to look.
(In reply to Ionen Wolkens from comment #7) > Created attachment 882985 [details] > telegram-desktop gdb backtrace.txt > > Not planning to really debug this, but attaching backtrace in case anyone > wants to look. It doesn't even build in my case due to codegen stage during src_compile().
I know I get the same failure when building, I was using the telegram-desktop I built before switching to disabling rdrand.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=666e7caae1dd37040ddff9afeca76786f20de1d3 commit 666e7caae1dd37040ddff9afeca76786f20de1d3 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2024-01-23 14:32:30 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2024-01-23 14:36:10 +0000 dev-qt/qtbase: revbump to ensure rdrand is enabled Following previous commit. Apologies for the rebuilds, can't rely on --changed-use to do the right thing here. Bug: https://bugs.gentoo.org/922498 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> dev-qt/qtbase/{qtbase-6.6.1-r3.ebuild => qtbase-6.6.1-r4.ebuild} | 0 1 file changed, 0 insertions(+), 0 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c1b0c6d2e86fcba4c9f198d3945c17f5d96dcc92 commit c1b0c6d2e86fcba4c9f198d3945c17f5d96dcc92 Author: Ionen Wolkens <ionen@gentoo.org> AuthorDate: 2024-01-23 14:28:38 +0000 Commit: Ionen Wolkens <ionen@gentoo.org> CommitDate: 2024-01-23 14:33:42 +0000 Revert "dev-qt/qtbase: add IUSE=cpu_flags_x86_rdrand" Regardless of if that worked or not, on second thought this was a bad idea. The flag is rather misleading for generic binhosts because they should actually *enable* it to allow optional usage (runtime detection). And then, this is actually broken on top, so let's just return to the previous state. This reverts commit c198f69e66547b5ba7d2ba1b9bae576ce93ee703. Bug: https://bugs.gentoo.org/922498 Signed-off-by: Ionen Wolkens <ionen@gentoo.org> dev-qt/qtbase/qtbase-6.6.1-r3.ebuild | 11 +---------- dev-qt/qtbase/qtbase-6.6.9999.ebuild | 11 +---------- dev-qt/qtbase/qtbase-6.7.9999.ebuild | 11 +---------- dev-qt/qtbase/qtbase-6.9999.ebuild | 11 +---------- 4 files changed, 4 insertions(+), 40 deletions(-)
I also have a few strange crashes in pyqt6 applications, in some fillrect function. One is https://bugs.gentoo.org/893206, another one is calibre (crashes at start in another fillrect, I tried to debug it over the weekend with no success). Could they be related?
Sounds likely if anything, if you want you could try to build telegram w/ USE=qt6 to see if it segfaults as comment #8 says. I don't believe the issue is limited to telegram. So, if -mno-rdrnd (which makes the ebuild pass -DQT_FEATURE_rdrnd=OFF) is the cause then I'm not sure I have an alternate solution to offer (and esp. not an ebuild one), beside trying to reproduce without the ebuild then taking it upstream. If haven't tried yet, maybe try to build it with -march=x86-64-v3 (don't use -mno-rdrnd). That -march=native reports -mrdrnd (comment #1) when it's unusable has me wondering and all the auto-detection that Qt does could result in something unexpected like asking for rdrnd to be enabled.
(In reply to Ionen Wolkens from comment #12) > alternate solution Sometime I'd almost want to make -DQT_FEATURE_x86intrin=OFF a USE for these odd cases that keep showing up. Unfortunately configure.cmake has a check to refuse disabling this on amd64/x86, and unsure if it even works if bypassed.
Wonder if in your case it's going to fail regardless of RDRND=OFF though? (if manage to get it to build). Guess there's some broken code path but I couldn't figure it out from looking at things that use rdrnd.
If I compile qtbase with -march=x86-64-v3 it still crashes. It seems bulding it with no support for RDRND creates a build that crashes even on cpus that support rdrnd properly. But if I compile it with -march=native and I force the test in src/corelib/global/qsimd.cpp to return true, all crashes go away. I can now run calibre, maestral_qt and telegram-desktop with this hack.
Update for qtbase-6.6.2: I still have to build it with -mno-rdrand -mno-rdseed, but it no longer crashes.
(In reply to Viorel Munteanu from comment #16) > Update for qtbase-6.6.2: I still have to build it with -mno-rdrand > -mno-rdseed, but it no longer crashes. That's good to hear.
$URL may or may not be related given currently suspected to be caused by rdrand being missing, with some luck it could fix this assuming it was still an issue
(In reply to Ionen Wolkens from comment #18) > $URL may or may not be related given currently suspected to be caused by > rdrand being missing, with some luck it could fix this assuming it was still > an issue (albeit think this cpu's case is special, so it's hard to say)
I still compile with -mno-rdrnd -mno-rdseed and I get warnings, but most things work. There are more CPUs with this problem. For some AMD released a fix in microcode, but for my CPU the latest microcode I could find does not have a fix. An upstream fix would be great.
(In reply to Viorel Munteanu from comment #20) > I still compile with -mno-rdrnd -mno-rdseed and I get warnings, but most > things work. There are more CPUs with this problem. For some AMD released > a fix in microcode, but for my CPU the latest microcode I could find does > not have a fix. An upstream fix would be great. Likely be a long shot, but may want to try if [1] does anything for you then. [1] https://codereview.qt-project.org/c/qt/qtbase/+/593073
(In reply to Ionen Wolkens from comment #21) > (In reply to Viorel Munteanu from comment #20) > > I still compile with -mno-rdrnd -mno-rdseed and I get warnings, but most > > things work. There are more CPUs with this problem. For some AMD released > > a fix in microcode, but for my CPU the latest microcode I could find does > > not have a fix. An upstream fix would be great. > Likely be a long shot, but may want to try if [1] does anything for you then. > > [1] https://codereview.qt-project.org/c/qt/qtbase/+/593073 This been merged upstream and backported to qtbase-6.7.2-r5 now. Be nice to know if it happened to help this bug and/or bug #893206 so can maybe close them.
Created attachment 903792 [details] A new build log for dev-qt/qtbase-6.7.2-r5
In my case it still doesn't build. This is the output of architecture_test: $ /mnt/extratmp/portage/dev-qt/qtbase-6.7.2-r5/work/qtbase-everywhere-src-6.7.2_build/config.tests/arch/architecture_test ==Qt=magic=Qt== Architecture:x86_64 ==Qt=magic=Qt== Sub-architecture: abm adx aes avx avx2 bmi bmi2 cx16 f16c fma fsgsbase lzcnt movbe pclmul popcnt prfchw rdpid rdrnd rdseed sha sse3 ssse3 sse4a sse4.1 sse4.2 sse4 ==Qt=magic=Qt== Build-ABI:x86_64-little_endian-lp64 Maybe I should also open a bug upstream?
Oh right sorry, had forgotten some context for this issue (was re-reading) and should re-asses this. First you probably should never use -march=znver2 (I see it in the build log), similarly to -march=bdver4 it enables rdrnd even if your cpu does not support it (myself I have a haswell without avx and -march=haswell would lead to SIGILL or other problems) As for -march=native, if it enables -mrdrnd then the issue is probably more with gcc than qtbase (for my haswell it resolves to -march=haswell -mno-avx). I don't "think" it'd make sense to file a bug to Qt. Does -march=native still does with current gcc? And what about clang? Not sure for how to check this with clang so can just do a macro test (can do the same with gcc too): $ clang -E -march=native - <<<"__RDRND__" | tail -n 1 1 (1 given enabled for me) The Qt fix I mentioned was fixing rdrnd issues even when building with -mno-rdrnd, so I guess it doesn't apply here. On a side-note, recent eclass changes should have been removing your -mno-rdrnd and converting it to -march=x86-64-v3 (which does not enable rdrnd but still enables most thigns znver2 supports).
Yes, both clang and gcc (including gcc 15) enable it, and -march=native resolves to znver2. I'll try with -march=x86-64-v3, see what it does.
I see, strange considering how "rdrand" doesn't show in your /proc/cpuinfo (for me it's there), would think they'd see it as unusable. Not that I know how they test for this.
$ cpuid -1 -r | head -3 CPU: 0x00000000 0x00: eax=0x00000010 ebx=0x68747541 ecx=0x444d4163 edx=0x69746e65 0x00000001 0x00: eax=0x00870f10 ebx=0x0e100800 ecx=0x7ed8320b edx=0x178bfbff ecx=0x7ed8320b has bit 30 set, so the CPUID instruction actually reports rdrand is supported. I think the kernel removes the flag from /proc/cpuinfo, because it checks it's buggy. I get this in dmesg at boot: [ 0.000022] RDRAND is not reliable on this platform; disabling.
(In reply to Viorel Munteanu from comment #28) > $ cpuid -1 -r | head -3 > CPU: > 0x00000000 0x00: eax=0x00000010 ebx=0x68747541 ecx=0x444d4163 > edx=0x69746e65 > 0x00000001 0x00: eax=0x00870f10 ebx=0x0e100800 ecx=0x7ed8320b > edx=0x178bfbff > > ecx=0x7ed8320b has bit 30 set, so the CPUID instruction actually reports > rdrand is supported. I think the kernel removes the flag from > /proc/cpuinfo, because it checks it's buggy. I get this in dmesg at boot: > > [ 0.000022] RDRAND is not reliable on this platform; disabling. I see, if really misreported then don't think anything can be done on either Qt nor gcc/clang ends then and is a case of RESOLVED CANTFIX here. Maybe kernel? At best I could test if rdrand is not usable and force it off in qt6-build.eclass, but this seem like you shouldn't let the compiler enable rdrnd globally even if Qt is the only one that complained about it.
Building with -march=x86-64-v3: dev-qt/qtbase-6.7.2-r4: crash (bug #893206, also calibre). dev-qt/qtbase-6.7.2-r5: no crash (both maestral-qt and calibre work). So I think both bugs can be closed, and I can open a new one against gcc so -march=native does not enable rdrnd/rdseed if they are buggy, even if they appear set in cpuid.
Ah, so the runtime rdrnd fix still did something for you then, that's nice.
Well, closing for now. It's an issue but per comment #29 and comment #30 can "probably" conclude it's not Qt's issue if something that is either broken or unsupported by the cpu is being enabled by *FLAGS. That aside, thinking about it, doing a Qt-only semi-heuristic workaround could be relatively easy in qt6-build.eclass' _qt6-build_sanitize_cpu_flags: 1. check if -march=native is used (implying being built for current machine) 2. check if compiler reports "__RDRND__" is set 3. check if /proc/cpuinfo does not list "rdrand" If all true, let the function sanitize (it uses full CXXFLAGS to determine the highest x86-64-v* usable as a replacement, prefer no -mno-* given Qt is picky with these). Might do that if we get reports from more users, I'd assume very few are affected given haven't heard from anyone but ceamac so far (in the bdver4 runtime case w/ 3 affected users or so, -march=native wasn't enabling rdrnd so that was different). But for now, I'll mark this WONTWORKAROUND.
