Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 908420 - dev-qt/qtbase-6.5.1-r1 emerge fails with -march=native
Summary: dev-qt/qtbase-6.5.1-r1 emerge fails with -march=native
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Qt Bug Alias
Depends on:
Reported: 2023-06-12 22:37 UTC by Georg
Modified: 2023-09-14 20:43 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---

dev-qt/qtbase-6.5.1-r1 build log (qtbase-6.5.1-r1-build.log,100.81 KB, text/x-log)
2023-06-12 23:01 UTC, Georg
emerge --info (emerge-info.txt,7.18 KB, text/plain)
2023-06-12 23:05 UTC, Georg
equery u qtbase (file_908420.txt,3.03 KB, text/plain)
2023-06-12 23:07 UTC, Georg
dev-qt/qtsvg-6.5.1 build log (qtsvg-6.5.1-build.log,33.19 KB, text/x-log)
2023-06-12 23:09 UTC, Georg
dev-qt/qtdeclarative-6.5.1 build log (file_908420.txt,58.29 KB, text/plain)
2023-06-12 23:12 UTC, Georg
lscpu (file_908420.txt,1.33 KB, text/plain)
2023-06-12 23:14 UTC, Georg
Intel i7-12800H flags (Intel_i7-12800H_flags,930 bytes, text/plain)
2023-06-15 15:56 UTC, Nathan Zachary
build.log (qtbase-6.5.1-r1-build.log,106.17 KB, text/x-log)
2023-07-06 00:17 UTC, vq24
environment (qtbase-6.5.1-r1-environment.txt,102.85 KB, text/plain)
2023-07-06 00:18 UTC, vq24

Note You need to log in before you can comment on or make changes to this bug.
Description Georg 2023-06-12 22:37:48 UTC
emerge --info:


equery u qtbase:

build log:

similar bug:

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:

dev-qt/qtdeclarative-6.5.1 build log:

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:
Comment 1 Georg 2023-06-12 22:47:09 UTC
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
Comment 2 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-06-12 22:51:16 UTC
Please attach all of the information rather than using pastebins, as they expire. Thanks.
Comment 3 Georg 2023-06-12 23:01:47 UTC
Created attachment 863747 [details]
dev-qt/qtbase-6.5.1-r1 build log
Comment 4 Georg 2023-06-12 23:05:25 UTC
Created attachment 863748 [details]
emerge --info
Comment 5 Georg 2023-06-12 23:07:13 UTC
Created attachment 863749 [details]
equery u qtbase
Comment 6 Georg 2023-06-12 23:09:06 UTC
Created attachment 863750 [details]
dev-qt/qtsvg-6.5.1 build log
Comment 7 Georg 2023-06-12 23:12:40 UTC
Created attachment 863751 [details]
dev-qt/qtdeclarative-6.5.1 build log
Comment 8 Georg 2023-06-12 23:14:06 UTC
Created attachment 863752 [details]
Comment 9 Mike Gilbert gentoo-dev 2023-06-13 00:58:44 UTC
It seems your CPU supports the FMA extension, but not AVX2. This should be reported to Qt upstream.
Comment 10 Luke A. Guest 2023-06-13 09:10:33 UTC
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.
Comment 11 Luke A. Guest 2023-06-13 09:13:43 UTC

Seem to be upstream bugs.
Comment 12 Nathan Zachary 2023-06-15 15:55:44 UTC
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.
Comment 13 Nathan Zachary 2023-06-15 15:56:33 UTC
Created attachment 863869 [details]
Intel i7-12800H flags
Comment 14 Marcin Deranek 2023-06-16 06:36:04 UTC
Similar thread on forums:
Comment 15 Chiitoo gentoo-dev 2023-06-18 17:43:14 UTC
(In reply to Luke A. Guest from comment #11)
> 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!
Comment 16 Nathan Zachary 2023-06-20 22:13:08 UTC
I have filed the following upstream bug:
Comment 17 Nathan Zachary 2023-06-21 02:45:56 UTC
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:

I'm not seeing this problem on any of my hosts running Gentoo directly on bare metal.
Comment 18 vq24 2023-07-06 00:16:48 UTC
Also got this on an AMD FX-8350 like Luke A. Guest
Comment 19 vq24 2023-07-06 00:17:41 UTC
Created attachment 865165 [details]

qtbase-6.5.1-r1 build.log
Comment 20 vq24 2023-07-06 00:18:45 UTC
Created attachment 865166 [details]

qtbase-6.5.1-r1 environment
Comment 21 Russell Dwiggins 2023-07-19 00:12:03 UTC
Fails here on AMD FX(tm)-8320 Eight-Core Processor <--- bare metal.
Comment 22 Matt Jolly gentoo-dev 2023-07-22 22:44:40 UTC
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.
Comment 23 Mike Gilbert gentoo-dev 2023-07-29 22:30:58 UTC
Please file bug(s) upstream for each combination of flags that fail.
Comment 24 Larry the Git Cow gentoo-dev 2023-09-05 13:05:41 UTC
The bug has been closed via the following commit(s):

commit 47709089ee12235f32005aa2295aec843164af16
Author:     Ionen Wolkens <>
AuthorDate: 2023-09-02 00:04:21 +0000
Commit:     Ionen Wolkens <>
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> -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.
    Signed-off-by: Ionen Wolkens <>

 eclass/qt6-build.eclass | 35 ++++++++++++++++++++++++++++++++++-
 1 file changed, 34 insertions(+), 1 deletion(-)

Additionally, it has been referenced in the following commit(s):

commit aa6feab907d063181e5bebeb052c3bd72843449b
Author:     Ionen Wolkens <>
AuthorDate: 2023-09-02 06:09:58 +0000
Commit:     Ionen Wolkens <>
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.
    Signed-off-by: Ionen Wolkens <>

 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(-)
Comment 25 Larry the Git Cow gentoo-dev 2023-09-14 20:43:49 UTC
The bug has been referenced in the following commit(s):

commit d863cc9d8ea3722e0ecd6c17e89d88830b45f4fb
Author:     Ionen Wolkens <>
AuthorDate: 2023-09-13 12:58:55 +0000
Commit:     Ionen Wolkens <>
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.
    Signed-off-by: Ionen Wolkens <>

 eclass/qt6-build.eclass | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)