Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 552942 - dev-qt/qtcore:5 forces -msse2 -mfpmath=sse on x86 (was: uic illegal instruction on Athlon XP)
Summary: dev-qt/qtcore:5 forces -msse2 -mfpmath=sse on x86 (was: uic illegal instructi...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Library (show other bugs)
Hardware: x86 Linux
: Normal normal with 1 vote (vote)
Assignee: Qt Bug Alias
URL:
Whiteboard:
Keywords:
: 559272 568442 (view as bug list)
Depends on:
Blocks: qt-5.5.1-stable
  Show dependency tree
 
Reported: 2015-06-23 16:37 UTC by Oleh
Modified: 2019-11-25 22:29 UTC (History)
4 users (show)

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


Attachments
qtwidgets-5.4.2 failure log (qtwidgets-5.4.2.log,44.28 KB, text/plain)
2015-06-23 16:38 UTC, Oleh
Details
/proc/cpuinfo (cpuinfo,586 bytes, text/plain)
2015-06-24 04:47 UTC, Oleh
Details
emerge --info (emerge.info,5.00 KB, text/plain)
2015-06-25 14:15 UTC, Oleh
Details
athlon (athlon.s,1.91 KB, text/plain)
2015-06-27 13:55 UTC, Oleh
Details
native (native.s,2.30 KB, text/plain)
2015-06-27 13:55 UTC, Oleh
Details
qtwidgets-5.4.2(-mno-prfchw -mno-sahf) log (qtwidgets-5.4.2-(-mno-prfchw -mno-sahf).log,45.51 KB, text/x-log)
2015-06-27 15:19 UTC, Oleh
Details
qtcore-succesful-build.log (qtcore.log,765.94 KB, text/x-log)
2015-06-28 12:21 UTC, Oleh
Details
qtgui-5.4.2-r1.log (qtgui-5.4.2-r1.log,125.57 KB, text/x-log)
2015-08-11 18:32 UTC, Oleh
Details
build.log (build.log,357.51 KB, text/x-log)
2015-08-12 09:40 UTC, Oleh
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oleh 2015-06-23 16:37:58 UTC
qtwidgets failing to build on Athlon XP. CPU detection false reports certain instruction enabled, sse4, avx, avx2 to name a few. Obviously, it's wrong. Compilation stops at 'Illegal instruction'

Reproducible: Always

Steps to Reproduce:
1. emerge qtwidgets:5
2. notice a build failure
3.
Actual Results:  
.obj/cppwriteiconinitialization.o .obj/cppwriteincludes.o .obj/cppwriteinitialization.o .obj/main.o .obj/uic.o   -L/usr/lib -lQt5Core -lpthread 
 [32;01m*[0m Running emake in src/widgets
make 
QT_PLUGIN_PATH=/var/tmp/portage/dev-qt/qtwidgets-5.4.2/work/qtbase-opensource-src-5.4.2/plugins LD_LIBRARY_PATH=/usr/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH} /var/tmp/portage/dev-qt/qtwidgets-5.4.2/work/qtbase-opensource-src-5.4.2/bin/uic dialogs/qfiledialog.ui -o .uic/ui_qfiledialog.h
Makefile:1354: recipe for target '.uic/ui_qfiledialog.h' failed
make: *** [.uic/ui_qfiledialog.h] Illegal instruction
 [31;01m*[0m ERROR: dev-qt/qtwidgets-5.4.2 failed (compile phase):
 [31;01m*[0m   emake failed
 [31;01m*[0m 
 [31;01m*[0m If you need support, post the output of `emerge --info '=dev-qt/qtwidgets-5.4.2'`,
 [31;01m*[0m the complete build log and the output of `emerge -pqv '=dev-qt/qtwidgets-5.4.2'`.
 [31;01m*[0m The complete build log is located at '/var/tmp/portage/dev-qt/qtwidgets-5.4.2/temp/build.log'.
 [31;01m*[0m The ebuild environment file is located at '/var/tmp/portage/dev-qt/qtwidgets-5.4.2/temp/environment'.
 [31;01m*[0m Working directory: '/var/tmp/portage/dev-qt/qtwidgets-5.4.2/work/qtbase-opensource-src-5.4.2/src/widgets'
 [31;01m*[0m S: '/var/tmp/portage/dev-qt/qtwidgets-5.4.2/work/qtbase-opensource-src-5.4.2'

Expected Results:  
qtwidgets compiled and installed
Comment 1 Oleh 2015-06-23 16:38:26 UTC
Created attachment 405592 [details]
qtwidgets-5.4.2 failure log
Comment 2 Oleh 2015-06-24 04:47:19 UTC
Created attachment 405618 [details]
/proc/cpuinfo
Comment 3 Mike Gilbert gentoo-dev 2015-06-25 00:30:50 UTC
Please provide emerge --info.
Comment 4 Oleh 2015-06-25 14:15:41 UTC
Created attachment 405720 [details]
emerge --info
Comment 5 Davide Pesavento gentoo-dev 2015-06-26 23:25:31 UTC
any particular reason you don't use -march=native?
Comment 6 Oleh 2015-06-27 05:48:16 UTC
well, this kind of workaround is a guess game. It is very similar to #447368.
It make avx, avx2, sse4 (and others) detected and passed corresponding -mavx, -mavx2, -msse4 flags into compilation.
Comment 7 Davide Pesavento gentoo-dev 2015-06-27 11:27:38 UTC
Can you just answer my question please?

(In reply to Oleg from comment #6)
> It make avx, avx2, sse4 (and others) detected and passed corresponding
> -mavx, -mavx2, -msse4 flags into compilation.

Nope, I don't see any -mavx/avx2/sse* while compiling uic in your build log...
Comment 8 Davide Pesavento gentoo-dev 2015-06-27 11:38:44 UTC
Also do the following:

$ touch empty.cpp
$ g++ -S -fverbose-asm -march=athlon-xp -o athlon.s empty.cpp
$ g++ -S -fverbose-asm -march=native -o native.s empty.cpp

and attach the resulting athlon.s and native.s files.
Comment 9 Oleh 2015-06-27 11:43:15 UTC
(In reply to Davide Pesavento from comment #5)
> any particular reason you don't use -march=native?
Again, i'm not going to play into guess games. Answer with question does not help to resolve the problem and quite abrasive. If you want me to change march to track the issue, then ask:
"Please, change the march to native and try to compile qtwidgets again. Post results. This will help me to track the problem"
Comment 10 Davide Pesavento gentoo-dev 2015-06-27 11:53:03 UTC
I misunderstood your answer (and mentioning bug 447368 didn't help). Actually I still don't understand it. If you're referring to -march=native being a "guess game", then from my experience the compiler has been way more accurate at guessing the various flags for my cpu than me setting a particular -march=...

So, to rephrase, what I want to know is what the compiler thinks about your cpu.
Comment 11 Oleh 2015-06-27 13:55:33 UTC
Created attachment 405858 [details]
athlon
Comment 12 Oleh 2015-06-27 13:55:55 UTC
Created attachment 405860 [details]
native
Comment 13 Davide Pesavento gentoo-dev 2015-06-27 14:14:49 UTC
Thanks. According to your compiler the difference is in the prfchw and sahf flags.
Now add -mno-prfchw and -mno-sahf to your C(XX)FLAGS, and rebuild qtcore and qtwidgets with them.
Comment 14 Oleh 2015-06-27 15:18:01 UTC
qtcore passed, qtwidgets roughly the same failure.
Comment 15 Oleh 2015-06-27 15:19:08 UTC
Created attachment 405862 [details]
qtwidgets-5.4.2(-mno-prfchw -mno-sahf) log
Comment 16 Davide Pesavento gentoo-dev 2015-06-27 15:26:23 UTC
Can you determine where the illegal instruction happens? Hint: build with -ggdb and run the last command (the one that fails) under gdb.
Comment 17 Oleh 2015-06-27 16:11:41 UTC
https://bugreports.qt.io/browse/QTBUG-35430
https://bugs.archlinux.org/task/38796
it looks like a related problem.
Comment 18 Davide Pesavento gentoo-dev 2015-06-27 16:26:36 UTC
Attach the build.log for qtcore:5 please.
Comment 19 Oleh 2015-06-28 12:21:32 UTC
Created attachment 405906 [details]
qtcore-succesful-build.log
Comment 20 Davide Pesavento gentoo-dev 2015-06-28 12:55:36 UTC
There's your problem: the build system adds '-msse2 -mfpmath=sse' to the libQt5Core build.
Comment 21 Davide Pesavento gentoo-dev 2015-06-28 23:19:14 UTC
qt_module.prf:

sse2:!contains(QT_CPU_FEATURES.$$QT_ARCH,sse2):!host_build:!if(static:contains(QT_CONFIG, shared)) {
    # If the compiler supports SSE2, enable it unconditionally in all of Qt shared libraries
    # (and only the libraries). This is not expected to be a problem because:
    # - on Windows, sharing of libraries is uncommon
    # - on Mac OS X, all x86 CPUs already have SSE2 support (we won't even reach here)
    # - on Linux, the dynamic loader can find the libraries on LIBDIR/sse2/
    # The last guarantee does not apply to executables and plugins, so we can't enable for them.
    QT_CPU_FEATURES.$$QT_ARCH += sse sse2
    QMAKE_CFLAGS += $$QMAKE_CFLAGS_SSE2
    QMAKE_CXXFLAGS += $$QMAKE_CFLAGS_SSE2
}
Comment 22 Davide Pesavento gentoo-dev 2015-07-13 00:30:50 UTC
Let's see what upstream says...
Comment 23 Oleh 2015-07-22 06:10:46 UTC
ok, last comment in that report means it has no solution so far.
Comment 24 Davide Pesavento gentoo-dev 2015-08-07 00:25:48 UTC
yep, upstream rejected the patch stating that this behavior is by design.
Comment 25 Davide Pesavento gentoo-dev 2015-08-07 02:29:14 UTC
I've committed a workaround.
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/qt5-build.eclass?r1=1.22&r2=1.23

Let me know if it solves your problem (you have to rebuild qtcore after you sync, better if you rebuild all qt5 packages)
Comment 26 Oleh 2015-08-11 18:31:29 UTC
it's still failing for qtgui, however it might be a different problem, though sse2 mentioned in build.log
Comment 27 Oleh 2015-08-11 18:32:02 UTC
Created attachment 408808 [details]
qtgui-5.4.2-r1.log
Comment 28 Davide Pesavento gentoo-dev 2015-08-11 18:45:03 UTC
Attach a full build log please.
Comment 29 Oleh 2015-08-12 09:40:36 UTC
Created attachment 408848 [details]
build.log
Comment 30 Davide Pesavento gentoo-dev 2015-08-19 01:57:52 UTC
So... qdrawhelper.cpp is built without sse2 (obviously) and therefore includes a non-optimized version of qt_memfill{16,32}.
This would be fine, except that qdrawhelper_sse2.cpp is also built, because your CONFIG includes "sse2"[*], but this means that the sse2-optimized versions of qt_memfill{16,32} are also built, leading to the "multiple definition" error at link time.

[*] Technically, sse2 in CONFIG means that your compiler supports SSE2, which is true, and simd.prf only checks for that.


This is arguably another upstream bug. But instead of trying to fix this one too, after the workaround that I already applied, it's better and easier to properly solve the original problem and send the patch upstream, like I intended to do. That will require some time though.
Comment 31 Davide Pesavento gentoo-dev 2015-08-22 01:57:34 UTC
(In reply to Davide Pesavento from comment #25)
> I've committed a workaround.
> https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/qt5-build.
> eclass?r1=1.22&r2=1.23
> 

Reverted.
Comment 32 Davide Pesavento gentoo-dev 2015-09-01 18:41:13 UTC
*** Bug 559272 has been marked as a duplicate of this bug. ***
Comment 33 piotr5 2015-09-05 07:13:44 UTC
don't understand why this bug still is open. just add -mno-sse2 to your CFLAGS (and CXXFLAGS) before compiling any qt:5 stuff and configure will automatically be set up without sse2. IMHO the solution is to check the CPU_FLAGS_X86 environment, and explicitely enable/disable sse2 in the ebuild based on them instead or in addition to parsing CFLAGS. i.e. I see it not as a problem of upstream if CONFIG can be changed accordingly. also, autodetection of sse2 should be done in the ebuild file and not in qt. that's since raw packages are more likely to be cross-compiled for another computer, while ebuild files more often are used for the native system...

warning: I just compiled it, didn't try out yet if all sse2 is gone...
Comment 34 Michael Palimaka (kensington) gentoo-dev 2015-12-16 16:55:52 UTC
(In reply to piotr5 from comment #33)
> IMHO the solution is to check the
> CPU_FLAGS_X86 environment, and explicitely enable/disable sse2 in the ebuild
> based on them instead

Is a workaround like this acceptable (I can prepare a patch)? It would be nice to unblock stabilisation.
Comment 35 Davide Pesavento gentoo-dev 2015-12-17 18:43:46 UTC
Sorry for the lack of updates.

I've found a much simpler solution that I'd like to try, but which I haven't had time to implement yet. I'll try to do that in the next few days.
Comment 36 Davide Pesavento gentoo-dev 2015-12-18 23:31:45 UTC
*** Bug 568442 has been marked as a duplicate of this bug. ***
Comment 37 Sernin van de Krol 2015-12-26 21:32:27 UTC
I found that adding "-mno-sse2" to my CFLAGS and/or CXXFLAGS solves the problem. Somewhere around line 538 I found the following checks in the qt5-build eclass:

        # instruction set support
        $(is-flagq -mno-sse2    && echo -no-sse2)
        $(is-flagq -mno-sse3    && echo -no-sse3)
        $(is-flagq -mno-ssse3   && echo -no-ssse3)
        $(is-flagq -mno-sse4.1  && echo -no-sse4.1)
        $(is-flagq -mno-sse4.2  && echo -no-sse4.2)

A more permanent solution would be to check CPU_FLAGS_X86 (maybe even USE?) for sse2, or at least give a warning if sse2 is missing in that list AND "-mno-sse2" is missing in CFLAGS. That way the user is at least properly educated about CPU_FLAGS_x86 and people wanting to build qt5 on older hardware can do so without too much trouble.

@Davide: I'll still test your solution when it comes, in the meantime I'll be using the above 'fix'.
Comment 38 Michael Palimaka (kensington) gentoo-dev 2016-01-29 09:39:45 UTC
Apparently we also need to account for qtdeclarative when sse2 is missing: http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtdeclarative.git/tree/qtdeclarative-opensource-src-5.5.0-no_sse2.patch
Comment 39 Davide Pesavento gentoo-dev 2016-02-04 19:08:27 UTC
I've finally committed a fix https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=cd0a7211f461a839bd7ad95571b25924d491138a

Please sync your trees in a couple of hours and let me know if it works for you. I tested locally with -march=core2 on an Ivy Bridge CPU and it gives the expected result.
Comment 40 Davide Pesavento gentoo-dev 2016-02-04 19:10:44 UTC
Remember to rebuild qtcore:5 first, then the affected module(s), e.g. qtwidgets.
Comment 41 Davide Pesavento gentoo-dev 2016-02-11 02:00:04 UTC
I've extended the fix to all other arches (well, amd64 in practice) in commit 4508bd5573404563769986101efd36677be05d48, and revbumped qtcore.

I'm going to consider this bug fixed. Please reopen if you still have problems.
Comment 42 Larry the Git Cow gentoo-dev 2018-12-27 20:37:52 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 <chiitoo@gentoo.org>
AuthorDate: 2018-12-27 20:26:49 +0000
Commit:     Jimi Huotari <chiitoo@gentoo.org>
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 <chiitoo@gentoo.org>

 eclass/qt5-build.eclass | 5 -----
 1 file changed, 5 deletions(-)
Comment 43 Larry the Git Cow gentoo-dev 2019-02-07 22:09:27 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 <chiitoo@gentoo.org>
AuthorDate: 2018-12-27 20:26:49 +0000
Commit:     Andreas Sturmlechner <asturm@gentoo.org>
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 <chiitoo@gentoo.org>
    Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>

 eclass/qt5-build.eclass | 5 -----
 1 file changed, 5 deletions(-)
Comment 44 Rutger van Bergen 2019-11-25 22:29:15 UTC
It seems that the revert of the workaround that was reported by Larry the Git Cow reintroduced (one of) the issues it apparently solved. This is discussed in bug #648004, to which a number of (alternative) qt5-build.eclass patches have now been attached.