Bug 672946 – >=dev-qt/qtgui-5.12 - In file included from painting/qdrawhelper_avx2.cpp:40: /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/include/avx2intrin.h:574:1: error: inlining failed in call to always_inline ‘__m256i _mm256_or_si256(__m256i, __m256i)’: target

• Status: RESOLVED FIXED
• Product: Gentoo Linux

[Description Voltage 2018-12-11 20:30:03 UTC]

Created attachment 557598 [details]
emerge --info '=dev-qt/qtgui-5.12.0::qt'

I can not build qtgui-5.12 from overlay. The problem is probably the lack of support for the instruction set by my processor (IvyBridge 3210m without avx2).

[Comment 1 Voltage 2018-12-11 20:30:26 UTC]

Created attachment 557600 [details]
build.log

[Comment 2 jospezial 2018-12-13 21:47:15 UTC]

Same here.

cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 15
model name      : Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz
stepping        : 11
microcode       : 0xb6
cpu MHz         : 2516.583
cache size      : 4096 KB
physical id     : 0
siblings        : 4
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good nopl cpuid aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi flexpriority dtherm
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf
bogomips        : 5035.79
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:


I fixed it for me with

diff --git a/dev-qt/qtgui/qtgui-5.12.9999.ebuild b/dev-qt/qtgui/qtgui-5.12.9999.ebuild
index 6f6d4286..dc5cf076 100644
--- a/dev-qt/qtgui/qtgui-5.12.9999.ebuild
+++ b/dev-qt/qtgui/qtgui-5.12.9999.ebuild
@@ -154,6 +154,9 @@ src_configure() {
                $(usex gif '' -no-gif)
                -gui
                -system-harfbuzz
+               -disable-avx
+               -disable-avx2
+               -disable-avx512
                $(qt_use jpeg libjpeg system)

[Comment 3 Markus 2018-12-17 08:46:01 UTC]

Same here with "AMD FX(tm)-8350 Eight-Core Processor", also without avx2.

The problem is in "config.tests/x86_simd/main.cpp", they try to detect avx2 with:
#if T(AVX2)
attribute_target("avx2") void test_avx2()
{
    _mm256_zeroall();
    __m256i a = _mm256_setzero_si256();
    __m256i b = _mm256_and_si256(a, a);
    (void) _mm256_add_epi8(a, b);
}
#endif

And this tests seems to succeed although AVX2 is not available.

[Comment 4 Markus 2018-12-17 10:31:07 UTC]

To be more precise:
The build of the test functions works. But it is never executed within main.
When I modify the main to also call the test function, it fails with "Illegal instruction".

[Comment 5 jospezial 2018-12-22 04:11:52 UTC]

http://code.qt.io/cgit/qt/qtbase.git/commit/?id=b6cd5fdc6b7c799a80126659f35801af9a26601a
"configure: inline openssl test sources"



These lines break latest 5.12 live ebuilds because folder config.tests/common is gone:

diff --git a/eclass/qt5-build.eclass b/eclass/qt5-build.eclass
index 83f66220..ce4c3e6e 100644
--- a/eclass/qt5-build.eclass
+++ b/eclass/qt5-build.eclass
@@ -180,8 +180,8 @@ qt5-build_src_prepare() {
 
                # Don't inject -msse/-mavx/... into CXXFLAGS when detecting
                # compiler support for extended instruction sets (bug 552942)
-               find config.tests/common -name '*.pro' -type f -execdir \
-                       sed -i -e '/QMAKE_CXXFLAGS\s*+=/ d' '{}' + || die
+               #find config.tests/common -name '*.pro' -type f -execdir \
+               #       sed -i -e '/QMAKE_CXXFLAGS\s*+=/ d' '{}' + || die
 
                # Don't add -O3 to CXXFLAGS (bug 549140)
                sed -i -e '/CONFIG\s*+=/ s/optimize_full//' \

[Comment 6 Chiitoo 2018-12-27 19:40:26 UTC]

(In reply to jospezial from comment #5)
> diff --git a/eclass/qt5-build.eclass b/eclass/qt5-build.eclass
> index 83f66220..ce4c3e6e 100644
> --- a/eclass/qt5-build.eclass
> +++ b/eclass/qt5-build.eclass
> @@ -180,8 +180,8 @@ qt5-build_src_prepare() {
>  
>                 # Don't inject -msse/-mavx/... into CXXFLAGS when detecting
>                 # compiler support for extended instruction sets (bug 552942)
> -               find config.tests/common -name '*.pro' -type f -execdir \
> -                       sed -i -e '/QMAKE_CXXFLAGS\s*+=/ d' '{}' + || die
> +               #find config.tests/common -name '*.pro' -type f -execdir \
> +               #       sed -i -e '/QMAKE_CXXFLAGS\s*+=/ d' '{}' + || die
>  
>                 # Don't add -O3 to CXXFLAGS (bug 549140)
>                 sed -i -e '/CONFIG\s*+=/ s/optimize_full//' \

This seems to have been broken since 2017, 5.9.something [1], where they moved things around...

Though if this bug is indeed related to that, it would make me wonder why people were not hitting it earlier than this, and I'm not sure if just refactoring the workaround will fix it.

1. http://code.qt.io/cgit/qt/qtbase.git/commit/config.tests/common?id=f54f7d84

[Comment 7 Larry the Git Cow 2018-12-27 20:37:55 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/qt.git/commit/?id=bafd5b0b9e0a2678334355ee3547ebf09833749b

commit bafd5b0b9e0a2678334355ee3547ebf09833749b
Author:     Jimi Huotari <[e-mail]>
AuthorDate: 2018-12-27 20:26:49 +0000
Commit:     Jimi Huotari <[e-mail]>
CommitDate: 2018-12-27 20:26:49 +0000

    qt5-build.eclass: remove obsolete instruction sets workaround
    
    This has seemingly been broken since 2017-08-02, where things
    were moved around [1], and now causes build failures as the
    directory has been removed completely [2].
    
    1. https://code.qt.io/cgit/qt/qtbase.git/commit/?id=f54f7d84
    2. https://code.qt.io/cgit/qt/qtbase.git/commit/?id=73b87697
    
    Bug: https://bugs.gentoo.org/552942
    Bug: https://bugs.gentoo.org/672946
    Signed-off-by: Jimi Huotari <[e-mail]>

 eclass/qt5-build.eclass | 5 -----
 1 file changed, 5 deletions(-)

[Comment 8 gerion 2019-01-06 03:57:26 UTC]

I hit the same error today. The referenced commit does not fix it for me.

[Comment 9 Chiitoo 2019-01-06 12:47:36 UTC]

(In reply to gerion from comment #8)
> I hit the same error today. The referenced commit does not fix it for me.

Yeah, it (comment 7) was mainly just to fix building on any system at all.

You might try what's mentioned in comment 2, if you didn't yet.  Perhaps we'll need some kind of a test that would in required cases do just that.

[Comment 10 Cecil Curry 2019-01-23 06:49:28 UTC]

Lamentably, I just hit this on a decrepit AMD Athlon II X2 240. Equally lamentably, I have nothing meaningful to contribute. It is a bit disconcerting that this passed upstream regression tests, but... here we are.

[Comment 11 Larry the Git Cow 2019-02-07 22:09:31 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=35ec5628b90bdc7ad6bb8ccc9e603100ad642cd9

commit 35ec5628b90bdc7ad6bb8ccc9e603100ad642cd9
Author:     Jimi Huotari <[e-mail]>
AuthorDate: 2018-12-27 20:26:49 +0000
Commit:     Andreas Sturmlechner <[e-mail]>
CommitDate: 2019-02-07 22:08:58 +0000

    qt5-build.eclass: remove obsolete instruction sets workaround
    
    This has seemingly been broken since 2017-08-02, where things
    were moved around [1], and now causes build failures as the
    directory has been removed completely [2].
    
    1. https://code.qt.io/cgit/qt/qtbase.git/commit/?id=f54f7d84
    2. https://code.qt.io/cgit/qt/qtbase.git/commit/?id=73b87697
    
    Bug: https://bugs.gentoo.org/552942
    Bug: https://bugs.gentoo.org/672946
    Signed-off-by: Jimi Huotari <[e-mail]>
    Signed-off-by: Andreas Sturmlechner <[e-mail]>

 eclass/qt5-build.eclass | 5 -----
 1 file changed, 5 deletions(-)

[Comment 12 Duncan 2019-02-15 05:26:49 UTC]

Please update the summary to qtgui-5.12.1.  I had seen this bug but since it only said 5.12, I had hoped it was fixed with 5.12.1.  Obviously no such luck. =:^(

Similar hardware to Markus but less cores, fx6100.

The suggested ebuild patch in comment#2 (modified to omit the -disable-avx bit since I have that) seems to have worked.  It just finished merging successfully. =:^)

[The live-git plasma-integration-9999 and plasma-workspace-9999 builds from the kde overlay now won't build without qt-12, which of course isn't in the gentoo or kde repos yet, so I had to re-add the qt overlay back to get it.  With live and upcoming kdes now requiring qt 5.12 broader use and more bug reports are likely.]

[Comment 13 Lars Wendler (Polynomial-C) (RETIRED) 2019-03-01 16:04:50 UTC]

This now also affects qtgui-5.12.1 from ::gentoo

[Comment 14 Nikos Chantziaras 2019-03-01 16:59:24 UTC]

Doesn't build here either.

[Comment 15 Mike Gilbert 2019-03-01 18:30:11 UTC]

It seems like the build system should be adding -mavx2 to the compiler command for this file.

Is Gentoo doing any patching/sed-ing that might prevent that?

[Comment 16 Denis Kaganovich 2019-03-02 00:07:02 UTC]

First: there are only -march=native problem: -march=native translating to full features list "-march=... -msse ... -mno-avx2 ..." (for example). Most simple & accurate way I found - after configure do:

sed -i -e 's:\$(CXXFLAGS) -march=:$(subst -march=native,-mtune=native,$(CXXFLAGS)) -march=:' "${S}"/src/gui/Makefile

- there are replacement -march=native to -mtune=native before next -march.

Also good idea to add useflag "bindist" & "if !bindist" - unswitch unused features, but I have no free time to explore more.

[Comment 17 Nikos Chantziaras 2019-03-02 01:22:18 UTC]

Since there's CPU_FLAGS_X86 in make.conf, perhaps the relevant Qt configure flags should be set accordingly? There's no point building the AVX512-enabled codepaths of Qt on a system that doesn't actually have it.

The configure flags are:

-sse2, -sse3, -ssse3, -sse4.1, -sse4.2, -avx, -avx2, -avx512

When the relevant instruction set is not listed in CPU_FLAGS_X86, it should be disabled with "-no-". For example -no-avx2 -no-avx512

[Comment 18 Mike Gilbert 2019-03-02 01:43:36 UTC]

I believe the software is designed to build support for all cpu variants, and detect the appropriate code to execute at runtime.

Disabling instructions at build time is a workaround at best.

[Comment 19 Mike Gilbert 2019-03-02 01:50:35 UTC]

(In reply to Denis Kaganovich from comment #16)

I think you don't understand how -march and -mavx2 interact. The latter always gets moved after the former when gcc invokes cc1, so -mavx2 wins.

I have no idea what you are proposing bindist; I suspect you don't understand the purpose of that USE flag.

[Comment 20 Mike Gilbert 2019-03-02 02:04:45 UTC]

Hmm, it looks like the build is passing -march=native from CXXFLAGS, and then appending -march=core-avx2 from the build system. Possibly those two options do not play well together.

[Comment 21 Nikos Chantziaras 2019-03-02 02:22:10 UTC]

(In reply to Mike Gilbert from comment #20)
> Hmm, it looks like the build is passing -march=native from CXXFLAGS, and
> then appending -march=core-avx2 from the build system. Possibly those two
> options do not play well together.

Doesn't look like that's the issue. The following builds fine if -march=core-avx2 is used and it doesn't matter if -march=native also appears or not (or where):

#include <immintrin.h>

int main()
{
    _mm256_set1_epi16(256);
}

[Comment 22 Nikos Chantziaras 2019-03-02 02:28:51 UTC]

Disregard my previous post. Actually -march=native is exactly the problem the build fails. I used the wrong instruction in my test program.

This reproduces the issue:

#include <immintrin.h>

int main()
{
    __m256i a;
    _mm256_andnot_si256(a, a);
}

With just -march=core-avx2 it builds fine. If -march=native is also present, it doesn't.

[Comment 23 Mike Gilbert 2019-03-02 02:41:40 UTC]

Created attachment 567326 [details, diff]
Pass -mavx2 instead of -march=core-avx2

I think this patch should resolve the build failure.

[Comment 24 Mike Gilbert 2019-03-02 02:56:41 UTC]

(In reply to Denis Kaganovich from comment #16)

It turns out you were on the right track by pointing out the failure with -march=native. Apologies for my earlier comment.

[Comment 25 Larry the Git Cow 2019-03-02 04:44:24 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1488107891b5800d923f2cd45a3ceea693104052

commit 1488107891b5800d923f2cd45a3ceea693104052
Author:     Mike Gilbert <[e-mail]>
AuthorDate: 2019-03-02 04:43:36 +0000
Commit:     Mike Gilbert <[e-mail]>
CommitDate: 2019-03-02 04:43:36 +0000

    dev-qt/qtgui: fix build with CXXFLAGS="-march=native"
    
    Bug: https://bugs.gentoo.org/672946
    Package-Manager: Portage-2.3.59_p2, Repoman-2.3.12_p67
    Signed-off-by: Mike Gilbert <[e-mail]>

 dev-qt/qtgui/files/qt-5.12-gcc-avx2.patch | 29 +++++++++++++++++++++++++++++
 dev-qt/qtgui/qtgui-5.12.1.ebuild          |  4 ++++
 2 files changed, 33 insertions(+)

[Comment 26 Nikos Chantziaras 2019-03-02 04:55:01 UTC]

I think -mavx2 should be appended so that -march=core-avx2 is kept, because it keeps all the other stuff enabled. core-avx2 enables more than just AVX2, so disabling it might potentially affect code generation.

So:

-QMAKE_CFLAGS_ARCH_HASWELL           = -march=core-avx2
+QMAKE_CFLAGS_ARCH_HASWELL           = -march=core-avx2 -mavx2

[Comment 27 Mike Gilbert 2019-03-02 05:35:42 UTC]

(In reply to Nikos Chantziaras from comment #26)

The source file is composed mainly of compiler intrinsic functions that map to SIMD instructons, so I doubt it makes much difference in reality.

I think the build system should only add the the compiler flags it really needs. Forcing the code to be optimized specifically for haswell cores makes no sense.

[Comment 28 Davide Pesavento (RETIRED) 2019-03-02 06:44:34 UTC]

The commit[1] that introduced QMAKE_CFLAGS_ARCH_HASWELL says:

"This commit changes the AVX2-optimized code in QtGui to Haswell-
optimized instead. That means, for example, that qdrawhelper_avx2.cpp
can now use the FMA instructions."

So FWIU it's not just AVX2 but all instruction set extensions supported by Haswell (BMI, BMI2, FMA, etc.). Hence the patch doesn't look correct to me.

[1] http://code.qt.io/cgit/qt/qtbase.git/commit/?id=c3a4ec5d0bbd5f2710f4fd1d3bd4a2d7f0f507ad

[Comment 29 email200202 2019-03-02 07:54:16 UTC]

Same here with "Intel(R) Core(TM) i7 CPU 950" without avx or avx2

CPU_FLAGS_X86: mmx mmxext popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3

Thanks @jospezial, your ebuild patch saved my computer.

Can we modify the ebuild in the tree with @jospezial workaround until a proper fix is agreed on.

[Comment 30 Denis Kaganovich 2019-03-02 12:05:26 UTC]

Yes, I am try to append -mavx2 after -march=core-avx2 first and it works. But I say "accurate" ;).

1) We (I) don't know why upstream do "-mavx", etc, but single "-march=core-avx2". There can have unknown compatibility reason.
2) -mavx2 make ON avx2, but no underlaying options like -mavx, -msse*. So keep them disabled by "-march=native" can produce some unexpected behaviour.

So, I just suggest most agnostic & safe fix, respecting unknown upstream logic. You can test more... if you want.

[Comment 31 Denis Kaganovich 2019-03-02 12:13:56 UTC]

In other solution - don't forget to test "-msse2avx". There are strange option, working on gcc & as. Some of gcc versions, for example, don't pass them to assembler after -march=native, but pass if -avx enabled on cmdline stage (-march and -mavx). If you ready to test everything dark placed on every CPU... ;)

[Comment 32 Denis Kaganovich 2019-03-02 12:36:06 UTC]

PS fyi: -march=native, unlike others, work with special behaviour. gcc is running in 2 stages, first - unroll -march=native into long ("-march=... msse ... -mno-avx2") string and pass to other gcc instance. So, sometimes order & interaction of other options is differ (sometimes fixed later in next gcc versions like "-msse2avx", sometimes there still feature). Also I remember in fact (but not detail) - clang can do some option ordering else (but -march=native in clang is similar to gcc).

[Comment 33 Denis Kaganovich 2019-03-02 13:46:51 UTC]

PPS Anymore, all this features support more then your CPU have, required only if you plan to run code on other hardware, else there are just some overcoding. So, if you want to optionally remove future features, it mean you want something like "binary distribute" your build over various hardware, so IMHO "bindist" looks relevant useflag. But as soon no enthusiasts to this work - no question, I make same on gt4 times ago, but as soon all differs and on first try - compilation breaks - I will not use more time on this...

[Comment 34 Mike Gilbert 2019-03-02 15:30:56 UTC]

(In reply to Davide Pesavento from comment #28)
> The commit[1] that introduced QMAKE_CFLAGS_ARCH_HASWELL says:
> 
> "This commit changes the AVX2-optimized code in QtGui to Haswell-
> optimized instead. That means, for example, that qdrawhelper_avx2.cpp
> can now use the FMA instructions."

The source file can be compiled with -mavx2 without any -march setting. That tells me that the code does require the "FMA instructions", and this is an optional optimization that only affects compiler-generated code.

If the code is updated to use other compiler intrinsics that require other instruction sets, the appropriate -mXXX flags must also be added.

> So FWIU it's not just AVX2 but all instruction set extensions supported by Haswell (BMI, BMI2, FMA, etc.). Hence the patch doesn't look correct to me.

The patch makes the code compile, so it is correct in that regard. It better respects the user's CXXFLAGS, and that's a good thing in my opinion. It might not be exactly what upstream intends, but their intention broke with -march=native.

[Comment 35 Mike Gilbert 2019-03-02 15:32:23 UTC]

(In reply to Mike Gilbert from comment #34)
> The source file can be compiled with -mavx2 without any -march setting. That
> tells me that the code does require the "FMA instructions"

This should read "the code does NOT require...".

[Comment 36 Nikos Chantziaras 2019-03-02 16:36:35 UTC]

Upstream bug:

https://bugreports.qt.io/browse/QTBUG-71564

They say it's a GCC bug.

[Comment 37 Nikos Chantziaras 2019-03-02 16:37:27 UTC]

GCC bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69471

[Comment 38 Mart Raudsepp 2019-03-02 19:12:13 UTC]

Qt has absolutely NO business overriding our -march= choice. End of story imho and this GCC bug is a good thing to weed out upstreams that mess with it, so to say.

[Comment 39 jospezial 2019-03-02 19:49:26 UTC]

The gcc bug was fixed upstream in GCC trunk:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=269164

"Author: 	hjl
Date: 	Sat Feb 23 19:39:35 2019 UTC (6 days, 23 hours ago)
Changed paths: 	8
Log Message: 	

driver: Also prune joined switches with negation

When -march=native is passed to host_detect_local_cpu to the backend,
it overrides all command lines after it.  That means

$ gcc -march=native -march=skylake-avx512

is the treated as

$ gcc -march=skylake-avx512 -march=native

Prune joined switches with Negative and RejectNegative to allow
-march=skylake-avx512 to override previous -march=native on command-line.

gcc/

	PR driver/69471
	* opts-common.c (prune_options): Also prune joined switches
	with Negative and RejectNegative.
	* config/i386/i386.opt (march=): Add Negative(march=).
	(mtune=): Add Negative(mtune=).
	* doc/options.texi: Document Negative used together with Joined
	and RejectNegative.

gcc/testsuite/

	PR driver/69471
	* gcc.dg/pr69471-1.c: New test.
	* gcc.dg/pr69471-2.c: Likewise.
	* gcc.target/i386/pr69471-3.c: Likewise.

"

+1 for qt and others not overriding my -march=native setting.

[Comment 40 Davide Pesavento (RETIRED) 2019-03-02 20:05:40 UTC]

(In reply to Mike Gilbert from comment #34)
> (In reply to Davide Pesavento from comment #28)
> > The commit[1] that introduced QMAKE_CFLAGS_ARCH_HASWELL says:
> > 
> > "This commit changes the AVX2-optimized code in QtGui to Haswell-
> > optimized instead. That means, for example, that qdrawhelper_avx2.cpp
> > can now use the FMA instructions."
> 
> The source file can be compiled with -mavx2 without any -march setting. That
> tells me that the code does require the "FMA instructions", and this is an
> optional optimization that only affects compiler-generated code.
It may be using only AVX2 at the moment, but upstream clearly intends to use BMI and FMA in the future.

> If the code is updated to use other compiler intrinsics that require other
> instruction sets, the appropriate -mXXX flags must also be added.
Yes, that's what I meant with my comment. -mavx2 isn't (or won't be) sufficient.

[Comment 41 Davide Pesavento (RETIRED) 2019-03-02 20:07:42 UTC]

(In reply to Mart Raudsepp from comment #38)
> Qt has absolutely NO business overriding our -march= choice. End of story
> imho and this GCC bug is a good thing to weed out upstreams that mess with
> it, so to say.
Agreed. Upstream should list all the required -mavx, -mbmi, ... flags for the instruction sets used in the code, rather than setting a specific -march=.

[Comment 42 rx80 2019-03-02 20:37:30 UTC]

The GCC patch (comment 39) applies cleanly on GCC 8.3 and Qt compiles without problems.

I put the following 2 patches in /etc/portage/patches/sys-devel/gcc:

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386.opt?view=patch&r1=269164&r2=269163&pathrev=269164

and

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/opts-common.c?view=patch&r1=269164&r2=269163&pathrev=269164

[Comment 43 ak 2019-03-04 17:24:19 UTC]

I probably hit this one as well some time ago, avx2 related (https://bugreports.qt.io/browse/QTBUG-71564). But there was a way to bypass this by specifiyng cpu_flags_x86 in the ebuild, like this for example:
--- qtgui-5.12.1-r1.ebuild
+++ qtgui-5.12.1-r1.ebuild
@@ -15,6 +15,19 @@
 
 IUSE="accessibility dbus egl eglfs evdev +gif gles2 ibus
        jpeg +libinput +png tslib tuio +udev vnc +xcb"
+IUSE_CPU_FLAGS=(
+sse2
+sse3
+ssse3
+sse4_1
+sse4_2
+avx
+avx2
+avx512
+)
+IUSE+="
+${IUSE_CPU_FLAGS[@]/#/cpu_flags_x86_}
+"
 REQUIRED_USE="
        || ( eglfs xcb )
        accessibility? ( dbus xcb )
@@ -172,5 +185,9 @@
        if use libinput || use xcb; then
                myconf+=( -xkbcommon )
        fi
+       local _f
+       for _f in ${IUSE_CPU_FLAGS[@]}; do
+               myconf+=( $(qt_use cpu_flags_x86_${_f} ${_f/_/.}) )
+       done
        qt5-build_src_configure
 }

[Comment 44 Mike Gilbert 2019-03-04 17:28:48 UTC]

Adding cpu_flags_x86 is unnecessary with my patch and/or the gcc bug fix.

[Comment 45 wbrana 2019-03-05 08:44:00 UTC]

why qt 5.12 isn't masked?

[Comment 46 ak 2019-03-05 13:09:49 UTC]

(In reply to Mike Gilbert from comment #44)
> Adding cpu_flags_x86 is unnecessary with my patch and/or the gcc bug fix.

Ok, but if cpu_flags were there from the day one, we wouldn't even hit this one. A more general approach, so we won't hit possible future issues with say avx512 or other CPU instructions unsupported by older hardware.

[Comment 47 wbrana 2019-03-05 20:06:50 UTC]

(In reply to wbrana from comment #45)
> why qt 5.12 isn't masked?
It works for me. I expected opposite.

[Comment 48 Larry the Git Cow 2019-03-08 07:54:58 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/gcc-patches.git/commit/?id=28e55a54934fa758aa6af045b61bd8f268a9c11b

commit 28e55a54934fa758aa6af045b61bd8f268a9c11b
Author:     Sergei Trofimovich <[e-mail]>
AuthorDate: 2019-03-08 07:50:57 +0000
Commit:     Sergei Trofimovich <[e-mail]>
CommitDate: 2019-03-08 07:50:57 +0000

    8.3.0: allow -march=native override with -march=<arch>
    
    That fixes build breakage like https://bugs.gentoo.org/672946
    where Qt build system uses -march=core-avx2 instead of
    individual -mavx2 (and friends).
    
    Bug: https://bugs.gentoo.org/679738
    Bug: https://gcc.gnu.org/PR69471
    Bug: https://bugs.gentoo.org/672946
    Signed-off-by: Sergei Trofimovich <[e-mail]>

 8.3.0/gentoo/26_all_overridable_native.patch | 126 +++++++++++++++++++++++++++
 8.3.0/gentoo/README.history                  |   3 +
 2 files changed, 129 insertions(+)

[Comment 49 Andreas Sturmlechner 2019-04-21 20:01:01 UTC]

*** Bug 684010 has been marked as a duplicate of this bug. ***

[Comment 50 PhobosK 2019-09-14 21:28:28 UTC]

This seems to be fixed now in portage tree in dev-qt/qtgui-5.12.3-r1 and dev-qt/qtgui-5.12.4 with the patch qt-5.12-gcc-avx2.patch (which is actually the one proposed here and set as obsolate - https://672946.bugs.gentoo.org/attachment.cgi?id=567326 ) ...

Still someone of the Gentoo devs decided to bump to dev-qt/qtgui-5.12.5 (and all QT 5.12.5 BTW) without testing and without adding the patch mentioned above. Thus all QT upgrade fails (breaking whole KDE for example) in situations/hardware as described above (Mine is an AMD with no AVX support) :(

For those of you that hit this bug for dev-qt/qtgui-5.12.5, untill they fix the build - please add the patch from portage tree for dev-qt/qtgui-5.12.4 as an user patch in your /etc/portage/patches :)

[Comment 51 Chiitoo 2019-09-14 21:55:02 UTC]

(In reply to PhobosK from comment #50)
> This seems to be fixed now in portage tree in dev-qt/qtgui-5.12.3-r1 and
> dev-qt/qtgui-5.12.4 with the patch qt-5.12-gcc-avx2.patch (which is actually
> the one proposed here and set as obsolate -
> https://672946.bugs.gentoo.org/attachment.cgi?id=567326 ) ...
> 
> Still someone of the Gentoo devs decided to bump to dev-qt/qtgui-5.12.5 (and
> all QT 5.12.5 BTW)

As they should, since bumping just parts of Qt makes no sense (aside from maybe qtwebengine, but that's not really doable right now, and I digress).

> without testing

Perhaps they don't have the hardware to test it.  This is where the "testing" in 'arch' comes very much handy.  :]

> and without adding the patch mentioned
> above.

Perhaps there was an issue with it, or it was simply lost in the bump.  It happens.  I don't remember if we discussed anything regarding this particular patch in recent times... I do forget things, though.

> Thus all QT upgrade fails (breaking whole KDE for example) in
> situations/hardware as described above (Mine is an AMD with no AVX support)
> :(
> 
> For those of you that hit this bug for dev-qt/qtgui-5.12.5, untill they fix
> the build - please add the patch from portage tree for dev-qt/qtgui-5.12.4
> as an user patch in your /etc/portage/patches :)

Just to confirm, you're saying you fixed things with said patch for you?  That would indeed be helpful information.

Thanks!

[Comment 52 PhobosK 2019-09-14 22:12:54 UTC]

(In reply to Chiitoo from comment #51)

LOL :)

Sorry for my being annoyed above... but lately such "errors" happen too often especially with major packages.... 

Anyway - 
> Just to confirm, you're saying you fixed things with said patch for you? 
> That would indeed be helpful information.
> 
> Thanks!

Yes the applied patch for the other 5.12 versions in portage works fine with 5.12.5 ... And all QT GUI + dependents like KDE for example work fine too...



As for:
> Perhaps they don't have the hardware to test it.  This is where the
> "testing" in 'arch' comes very much handy.  :]

True - real hardware testing is the best option but... Perhaps there are some other options like - virtual machines - where one can choose the arch :)

Anyway this is not a forum... so I will stop here... Though IMHO the fact remains that when such major packages are bumped even as ~arch they should be thoroughly tested before the submission to portage, 'cause otherwise if they mess up they do it with the whole system :)

Thanks

[Comment 53 Mike Gilbert 2019-09-14 22:17:40 UTC]

The qtgui patch should be unnecessary if you have a recent version of gcc installed.

[Comment 54 PhobosK 2019-09-15 11:29:23 UTC]

Yeah probably this is true if using GCC 8.3.0 or above...

But the 8.3.0 is default (preferred) in Gentoo profile 17.1 and those of us that are still on 17.0 that came with GCC 7.3.0 as default still need the patch :)

Or need to set and rebuild with GCC 8.3.0 :)

[Comment 55 tt_1 2019-09-15 11:39:19 UTC]

Created attachment 589904 [details, diff]
backported patch

I think you should try to upgrade your gcc and profile, but since this can be very time consuming you might want to try to add the attached patch to your gcc-7.3.0 

the ebuild has epatch_user, so it is pulled in when dropped into /etc/portage/patches/sys-devel/gcc-7.3.0

it applies cleanly with patchlevel 1.8, but I haven't actually done any runtime testing with this

it's named gcc-8.3.0-pr69471, since that is where the backport came from

[Comment 56 Mike Gilbert 2019-09-15 15:06:25 UTC]

(In reply to PhobosK from comment #54)

gcc-8.3.0 work perfectly fine on a 17.0 profile. You should upgrade.

[Comment 57 Andreas Sturmlechner 2019-09-15 16:33:15 UTC]

Indeed there is no link whatsoever between GCC and profiles. Current ~arch version of GCC is 9.2.0.

So thanks very much for testing ~arch Qt 5.12.5 with arch/outdated toolchain, but don't complain that your particular arch/~arch mix wasn't tested beforehand.

[Comment 58 Larry the Git Cow 2019-09-15 16:51:53 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6a12587ba46aa919fd396195faa5d4ec784c5327

commit 6a12587ba46aa919fd396195faa5d4ec784c5327
Author:     Andreas Sturmlechner <[e-mail]>
AuthorDate: 2019-09-15 16:44:13 +0000
Commit:     Andreas Sturmlechner <[e-mail]>
CommitDate: 2019-09-15 16:51:41 +0000

    dev-qt/qtgui: Fix build with CXXFLAGS="-march=native"
    
    Old fix from 5.12.1 still applies.
    
    Reported-by: PhobosK <[e-mail]>
    Bug: https://bugs.gentoo.org/672946
    Package-Manager: Portage-2.3.76, Repoman-2.3.17
    Signed-off-by: Andreas Sturmlechner <[e-mail]>

 dev-qt/qtgui/qtgui-5.12.5.ebuild | 2 ++
 1 file changed, 2 insertions(+)

[Comment 59 Andreas Sturmlechner 2019-11-02 12:25:39 UTC]

*** Bug 699148 has been marked as a duplicate of this bug. ***

[Comment 60 Larry the Git Cow 2019-11-02 15:23:06 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=aa52bb1b8dedd9db585ea75e70ccbdc3d2bb2791

commit aa52bb1b8dedd9db585ea75e70ccbdc3d2bb2791
Author:     Andreas Sturmlechner <[e-mail]>
AuthorDate: 2019-11-02 12:38:00 +0000
Commit:     Andreas Sturmlechner <[e-mail]>
CommitDate: 2019-11-02 15:22:31 +0000

    dev-qt/qtgui: Fix build with CXXFLAGS="-march=native"
    
    Old fix from 5.12.1 still applies.
    
    Bug: https://bugs.gentoo.org/672946
    Package-Manager: Portage-2.3.78, Repoman-2.3.17
    Signed-off-by: Andreas Sturmlechner <[e-mail]>

 dev-qt/qtgui/qtgui-5.13.2.ebuild | 2 ++
 1 file changed, 2 insertions(+)

[Comment 61 Gabriele Pelissetto 2019-12-18 20:22:07 UTC]

*** Bug 703320 has been marked as a duplicate of this bug. ***

[Comment 62 Larry the Git Cow 2019-12-18 20:33:56 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9e38090b509d7e28731583665f91f63793b2f987

commit 9e38090b509d7e28731583665f91f63793b2f987
Author:     Andreas Sturmlechner <[e-mail]>
AuthorDate: 2019-12-18 20:33:37 +0000
Commit:     Andreas Sturmlechner <[e-mail]>
CommitDate: 2019-12-18 20:33:37 +0000

    dev-qt/qtgui: Fix build with CXXFLAGS="-march=native"
    
    Old fix from 5.12.1 still applies.
    
    Bug: https://bugs.gentoo.org/672946
    Package-Manager: Portage-2.3.78, Repoman-2.3.17
    Signed-off-by: Andreas Sturmlechner <[e-mail]>

 dev-qt/qtgui/qtgui-5.14.0.ebuild | 2 ++
 1 file changed, 2 insertions(+)

[Comment 63 Larry the Git Cow 2019-12-25 17:33:17 UTC]

The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/proj/qt.git/commit/?id=71a6ccc1bcc9b66bbb891365ab17edcd49f7b1c9

commit 71a6ccc1bcc9b66bbb891365ab17edcd49f7b1c9
Author:     Andreas Sturmlechner <[e-mail]>
AuthorDate: 2019-12-25 15:51:30 +0000
Commit:     Andreas Sturmlechner <[e-mail]>
CommitDate: 2019-12-25 17:30:33 +0000

    dev-qt/qtgui: Sync with Gentoo ebuild repository
    
    - Fix build with CXXFLAGS="-march=native"
    - Block known old users of _populate_Gui_plugin_properties
      With sufficiently parallelised emerge, if dev-qt/qtgui reverse dependencies
      are scheduled before modules installing Qt5Gui plugins have been rebuilt,
      these revdeps will fail cmake after an incompatible change in macro args.
    - Raise minimum dependency for USE=tslib
    
    Bug: https://bugs.gentoo.org/672946
    Bug: https://bugs.gentoo.org/703306
    Bug: https://bugs.gentoo.org/703336
    Package-Manager: Portage-2.3.83, Repoman-2.3.20
    Signed-off-by: Andreas Sturmlechner <[e-mail]>

 dev-qt/qtgui/files/qt-5.12-gcc-avx2.patch | 29 +++++++++++++++++++++++++++++
 dev-qt/qtgui/qtgui-5.12.9999.ebuild       |  2 ++
 dev-qt/qtgui/qtgui-5.14.9999.ebuild       | 15 ++++++++++++---
 dev-qt/qtgui/qtgui-5.15.9999.ebuild       | 15 ++++++++++++---
 dev-qt/qtgui/qtgui-5.9999.ebuild          |  2 +-
 5 files changed, 56 insertions(+), 7 deletions(-)

[Comment 64 jospezial 2024-10-10 02:20:05 UTC]

5 years later: Is this fixed? 
Old versions are gone. Can this be closed?