[SOLVED] Various KDE 6 application segfaults

[Ionen]

I really have few ideas of what may be happening here, my best "guess" was that dev-qt/* may have been enabling some broken feature when -march=native is passed for these cpus (could try building dev-qt/* without -march at all) -- but if binpkgs are used then it sounded doubtful.

It's instead possible that it detects a feature at runtime regardless and only use it then, and only affect this specific hardware for some reason. If we knew which it could potentially be disabled but well. Not to say this is necessarily the right route or that the issue is really in dev-qt/*.

I'd suggest building qtbase without intrinsics support to see if it helps (Edit: aka this disables runtime detection+usage of AVX and such), but upstream Qt has made this impossible for amd64/x86 a few versions ago and just gives an error if disable the feature.

[tranquilcool]

I really have few ideas of what may be happening here, my best "guess" was that dev-qt/* may have been enabling some broken feature when -march=native is passed for these cpus (could try building dev-qt/* without -march at all) -- but if binpkgs are used then it sounded doubtful.

It's instead possible that it detects a feature at runtime regardless and only use it then, and only affect this specific hardware for some reason. If we knew which it could potentially be disabled but well. Not to say this is necessarily the right route or that the issue is really in dev-qt/*.

I'd suggest building qtbase without intrinsics support to see if it helps, but upstream Qt has made this impossible for amd64/x86 a few versions ago and just gives an error if disable the feature.

Ok, I will try.

[tranquilcool]

I really have few ideas of what may be happening here, my best "guess" was that dev-qt/* may have been enabling some broken feature when -march=native is passed for these cpus (could try building dev-qt/* without -march at all) -- but if binpkgs are used then it sounded doubtful.

It's instead possible that it detects a feature at runtime regardless and only use it then, and only affect this specific hardware for some reason. If we knew which it could potentially be disabled but well. Not to say this is necessarily the right route or that the issue is really in dev-qt/*.

I'd suggest building qtbase without intrinsics support to see if it helps (Edit: aka this disables runtime detection+usage of AVX and such), but upstream Qt has made this impossible for amd64/x86 a few versions ago and just gives an error if disable the feature.

Incredible, I can't believe it!
I compiled qtbase without any -march and everything just works. I can launch plasma6 apps etc.
Now I am compiling kwin and plasma-workspace, of course with -march-native, (I started deleting 'em to go back to plasma5) before you
suggested a no -march qtbase compilation).
I think everything is just going to work.
I'll report back.
I am very grateful.
Thank you!

[Hu]

I wonder if the affected users have AVX support in hardware, but have it blocked by one of the software mitigations (probably for GDS (see linux.git:Documentation/admin-guide/hw-vuln/gather_data_sampling.rst)), and Qt isn't properly handling the case that the feature is in the CPU, but cannot be used. When -march is omitted, Qt then does not include the buggy AVX support at all, and works. This is all speculation on my part. I have not reviewed how Qt changes with the presence/absence of -march.

[tranquilcool]

I wonder if the affected users have AVX support in hardware, but have it blocked by one of the software mitigations (probably for GDS (see linux.git:Documentation/admin-guide/hw-vuln/gather_data_sampling.rst)), and Qt isn't properly handling the case that the feature is in the CPU, but cannot be used. When -march is omitted, Qt then does not include the buggy AVX support at all, and works. This is all speculation on my part. I have not reviewed how Qt changes with the presence/absence of -march.

I am totally ignorant about the technicalities of computing, so I wouldn't know. But I give these
information so that someone prepared could take a look.
This mobo has these, and there's an AVX and AVX2 among them:

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 acc_power nopl nonstop_tsc cpuid extd_apicid aperfmperf 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 xop skinit wdt lwp fma4 tce nodeid_msr tbm topoext perfctr_core perfctr_nb bpext ptsc mwaitx cpb hw_pstate ssbd vmmcall fsgsbase bmi1 avx2 smep bmi2 xsaveopt arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif overflow_recov
bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass retbleed

[pietinger]

I wonder if the affected users have AVX support in hardware, but have it blocked by one of the software mitigations [...] and Qt isn't properly handling the case that the feature is in the CPU, but cannot be used. When -march is omitted, Qt then does not include the buggy AVX support at all, and works. This is all speculation on my part. I have not reviewed how Qt changes with the presence/absence of -march.

If that is the case, then we can simply test it:

1. Checking current setting with:

Code: Select all

cat /sys/devices/system/cpu/vulnerabilities/gather_data_sampling

(Maybe it will gives: "Mitigation: AVX disabled, no microcode")

2a. Compile everything with march=native and set the kernel command line parameter: gather_data_sampling=off

( 2b. Ceck again with cat /sys/devices/system/cpu/vulnerabilities/gather_data_sampling )

... any segfaults now ?

[...] (see linux.git:Documentation/admin-guide/hw-vuln/gather_data_sampling.rst)),[...]

From this file:

The mitigation can be disabled by setting "gather_data_sampling=off" or "mitigations=off" on the kernel command line.
...
If used, these options will disable AVX use by turning off XSAVE YMM support. However, the processor will still enumerate AVX support. Userspace that does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM support will break.

[tranquilcool]

I wonder if the affected users have AVX support in hardware, but have it blocked by one of the software mitigations [...] and Qt isn't properly handling the case that the feature is in the CPU, but cannot be used. When -march is omitted, Qt then does not include the buggy AVX support at all, and works. This is all speculation on my part. I have not reviewed how Qt changes with the presence/absence of -march.

If that is the case, then we can simply test it:

1. Checking current setting with:

Code: Select all

cat /sys/devices/system/cpu/vulnerabilities/gather_data_sampling

(Maybe it will gives: "Mitigation: AVX disabled, no microcode")

2a. Compile everything with march=native and set the kernel command line parameter: gather_data_sampling=off

( 2b. Ceck again with cat /sys/devices/system/cpu/vulnerabilities/gather_data_sampling )

... any segfaults now ?

[...] (see linux.git:Documentation/admin-guide/hw-vuln/gather_data_sampling.rst)),[...]

From this file:

The mitigation can be disabled by setting "gather_data_sampling=off" or "mitigations=off" on the kernel command line.
...
If used, these options will disable AVX use by turning off XSAVE YMM support. However, the processor will still enumerate AVX support. Userspace that does not follow proper AVX enumeration to check both AVX *and* XSAVE YMM support will break.

This is what I see:

cat /sys/devices/system/cpu/vulnerabilities/gather_data_sampling
Not affected

[localtoast]

Well... wow, ok. I go to sleep for a few hours and this thread blows up with answers. This is pretty amazing if it works.

I have none of the kaccount-* installed.

Spectacle: I have masked: >=kde-apps/spectacle-24.05.2. Version 23.08.5 works fine.
But I prefer the old ksnap which is a lot better. Still works

Same for gwenview: masked >=kde-apps/gwenview-24.08.1 and use version 28.08.0-r1

Also watch out media-libs/kimageannotator and media-libs/kcolorpicker I had to mask the latest versions.

Thanks. It seems like the -23.08.* versions have already been removed for my version of the tree; I don't see ebuilds for them anymore. I can deal with not having them for a little while if I have to.

@localtoast: Before you do that, I would still rather recommend

1) to upgrade to KF-6.6.0 and Plasma 6.1.5, just because they are available in ~arch now
2) switch your away from CFLAGS="-march=native -mtune=native" to the generic settings used by gentoobinhost which you appear to be using, and rebuild the Qt packages.

[...]
If you do not use the Gentoo hosted binary packages, checkout this document to choose the right setting for your AMD FX-9800: https://wiki.gentoo.org/wiki/Safe_CFLAGS#FX-XXXX

Just to clarify where I am with this, asturm, I have gentoobinhost configured, but I don't recall ever having actually used it to install anything. - I always build from source. gcc appears to already detect bdver4 as native, which is slightly at odds with the document you linked saying the correct setting is bdver1. Should I interpret the 1 and 4 on the end as something like revision numbers, or is there likely to be a significant difference there, do you think? A quick Google doesn't seem to turn up any answers about the differences, but I'll keep looking.

EDIT: GCC documentation briefly describes them, and there are quite a lot of instruction sets supported by bdver4 that aren't supported by bdver1:

‘bdver1’

CPUs based on AMD Family 15h cores with x86-64 instruction set support. (This supersets FMA4, AVX, XOP, LWP, AES, PCLMUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and 64-bit instruction set extensions.)
[...]
‘bdver4’

AMD Family 15h core based CPUs with x86-64 instruction set support. (This supersets BMI, BMI2, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, AVX2, XOP, LWP, AES, PCLMUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and 64-bit instruction set extensions.)

I was going to say I'd take a swing at KF-6.6, but it looks like another solution has possibly presented itself...

Incredible, I can't believe it!
I compiled qtbase without any -march and everything just works. I can launch plasma6 apps etc.
Now I am compiling kwin and plasma-workspace, of course with -march-native, (I started deleting 'em to go back to plasma5) before you
suggested a no -march qtbase compilation).
I think everything is just going to work.
I'll report back.
I am very grateful.
Thank you!

Just so I'm sure I understand: tranquilcool, you built dev-qt/qtbase and nothing else with no -march and -mtune flags at all, or with like -march=generic? Did you still do -O2, or did you also turn off optimization? Did you mess with any CPU_FLAGS_X86 settings?

This is what I see:

cat /sys/devices/system/cpu/vulnerabilities/gather_data_sampling
Not affected

Exactly the same for me.

[tranquilcool]

Built qtbase with no march and non mtune. I never use mtune. And that was it.
I confirm, it works.
Thanks everybody.

[localtoast]

Built qtbase with no march and non mtune. I never use mtune. And that was it.
I confirm, it works.
Thanks everybody.

I'm gonna try this when I finish using the machine for work.

If it does work for me - and I assume it most likely will - then I will thank everyone for their input and help, then mark this thread solved, and update the upstream bug with KDE. Probably also need to file something with QT.

[Ionen]

Does "close to bdver4" generic -march=x86-64-v3 work fine (still gets you avx2 and such), rather than none at all? Be good to know if issue is limited to -march=bdver4

Also, I know tranquilcool's -march=native is bdver4 but what about yours localtoast to be sure? To be simple, can emerge app-misc/resolve-march-native and run the "resolve-march-native" command to see.

Does raise the question as to why this is happening, bug in qt? bug in gcc? I don't intend to dig into that myself (esp. given can't test/reproduce, with my cpu -march=bdver4 just causes qtbase to fail to build), but I could potentially do a ebuild workaround that swaps to x86-64-v3 when bdver4 is detected so other people don't run into this. Would also spare having to keep a package.env workaround for future builds.

[localtoast]

Does the baseline -march=x86-64-v3 work fine, rather than none at all? Be good to know if issue is limited to -march=bdver4

Also, I know tranquilcool's -march=native is bdver4 but what about yours localtoast to be sure? To be simple, can emerge app-misc/resolve-march-native and run the "resolve-march-native" command to see.

Does raise the question as to why this is happening, bug in qt? bug in gcc? I don't intend to dig into that myself (esp. given can't test/reproduce, with my cpu -march=bdver4 just causes qtbase to fail to build), but I could potentially do a ebuild workaround that swaps to x86-64-v3 when bdver4 is detected so other people don't run into this.

According to GCC, my native arch is bdver4. I checked it using the gcc one-liner at the top of the page asturm linked me to upthread, so I presume it's correct. I assume tranquilcool's is too but I don't think I've seen him explicitly state it anywhere.

I'm right now building qtbase with no march flag - I've used package.env to modify CFLAGS, CXXFLAGS, FCFLAGS and FFLAGS. As far as I understand it LDFLAGS is set in the profile and should be left alone, so I have left it alone. According to temp/build.log, the CFLAGS have been modified to "-O2 -pipe" and according to the output of ps | grep march, omitting the march flag is causing GCC to fall back to -mtune=generic -march=x86-64, which is what I thought it would do. One gcc process reads as follows:

Code: Select all

portage   9481  133  0.1  52552 17448 pts/5    R    19:01   0:00 /usr/libexec/gcc/x86_64-pc-linux-gnu/13/cc1plus -quiet -D_GNU_SOURCE -D HAVE_pollts /var/tmp/portage/dev-qt/qtbase-6.7.2-r4/work/qtbase-everywhere-src-6.7.2_build/CMakeFiles/CMakeScratch/TryCompile-dWnoqm/src.cxx -quiet -dumpdir CMakeFiles/cmTC_90abe.dir/ -dumpbase src.cxx.cxx -dumpbase-ext .cxx -mtune=generic -march=x86-64 -O2 -std=gnu++17 -fPIE -fcf-protection -o -

And the build.log is as follows:

Code: Select all

~ $ sudo grep O2 /var/tmp/portage/dev-qt/qtbase-6.7.2-r4/temp/build.log
            -DCMAKE_C_FLAGS=-O2 -pipe
            -DCMAKE_CXX_FLAGS=-O2 -pipe
C               -O2 -pipe
C++             -O2 -pipe

Like I said a couple posts ago, I think the only thing I can do - presuming that this solution works for me like it did for tranquilcool - is to update the KDE bug report with this new information and file a bug with QT with what information we have. Is it a gcc bug? I don't have even close to the wherewithal I need to determine this and, like you, I don't propose to try.

EDIT: Commencing Plasma 6 build now. See y'all in about 15 hours after qtwebengine is done. qtbase build went fine.

[Ionen]

If can confirm that -march=x86-64-v3 works too by rebuilding qtbase again and not just none, I already prepared a dirty workaround that I could push to qt6-build.eclass' _qt6-build_sanitize_cpu_flags, aka will sanitize if this is true:

Code: Select all

[[ ${PN} == qtbase ]] && tc-is-gcc &&
    [[ $($(tc-getCXX) -S -fverbose-asm ${CXXFLAGS} ${CPPFLAGS} \
        -x c++ -o - - <<<'' || die) == *-march=bdver4* ]]

Commit at https://termbin.com/u6vx if someone actually want to try it, albeit I already tested the logic and I don't see why it wouldn't work, question is more whether x86-64-v3 is fine or not. If it's not, I'd suspect something broken or quirky on these cpus rather than a potential bug in qtbase or gcc, given -v3 is common and not broken for anyone that I'm aware of (some binary distros also provide -v3 packages (we do!), albeit -v1-2 are far more common).

[localtoast]

If can confirm that -march=x86-64-v3 works too by rebuilding qtbase again and not just none, I already prepared a dirty workaround that I could push to qt6-build.eclass' _qt6-build_sanitize_cpu_flags, aka will sanitize if this is true:

Code: Select all

[[ ${PN} == qtbase ]] && tc-is-gcc &&
    [[ $($(tc-getCXX) -S -fverbose-asm ${CXXFLAGS} ${CPPFLAGS} \
        -x c++ -o - - <<<'' || die) == *-march=bdver4* ]]

Commit at https://termbin.com/u6vx if someone actually want to try it, albeit I already tested the logic and I don't see why it wouldn't work, question is more whether x86-64-v3 is fine or not. If it's not, I'd suspect something broken or quirky on these cpus rather than a potential bug in qtbase or gcc, given -v3 is common and not broken for anyone that I'm aware of (some binary distros also provide -v3 packages (we do!), albeit -v1-2 are far more common).

Give me a day or so, I will try to launch plasma with the qtbase version I've built omitting march, then when (if) that works, I'll rebuild qtbase specifically with x86-64-v3 and see what happens.

As an aside, I know Acer put a really freaky, intentionally crippled BIOS/UEFI in this laptop model in particular. They did stuff like intentionally and permanently disabling AMD-V, so I would be unsurprised if we one day determined that this was the result of a chipset quirk following from something else a BIOS or laptop vendor did in that vein and failed to document. This is unhelpful speculation at this point though, I'm just grumbling out loud.

[tranquilcool]

If can confirm that -march=x86-64-v3 works too by rebuilding qtbase again and not just none, I already prepared a dirty workaround that I could push to qt6-build.eclass' _qt6-build_sanitize_cpu_flags, aka will sanitize if this is true:

Code: Select all

[[ ${PN} == qtbase ]] && tc-is-gcc &&
    [[ $($(tc-getCXX) -S -fverbose-asm ${CXXFLAGS} ${CPPFLAGS} \
        -x c++ -o - - <<<'' || die) == *-march=bdver4* ]]

Commit at https://termbin.com/u6vx if someone actually want to try it, albeit I already tested the logic and I don't see why it wouldn't work, question is more whether x86-64-v3 is fine or not. If it's not, I'd suspect something broken or quirky on these cpus rather than a potential bug in qtbase or gcc, given -v3 is common and not broken for anyone that I'm aware of (some binary distros also provide -v3 packages (we do!), albeit -v1-2 are far more common).

I built dev-qt/qtbase with this:

-march=x86-64-v3

as you suggested, I can
confirm that it doesn’t work

It only works with no -march at all.

[Ionen]

I built dev-qt/qtbase with this:

-march=x86-64-v3

as you suggested, I can
confirm that it doesn’t work

It only works with no -march at all.

I see, that's too bad. Does x86-64-v2 fare any better? Maybe something up with AVX.

Either way that makes working around it difficult now, I have no real way to tell if the hardware is affected, at best =bdver4 is now more of a "guess" that it may be affected. In theory even the x86-64-v3 binary packages may be affected now (despite being fine for everyone else).

Perhaps not all bdver4 are affected too, so replacing bdver4 may be wrong for most users.

May need to keep the local-only package.env workaround, unsure if will do anything about this in the ebuild unless someone figures out the right fix.

[tranquilcool]

I built dev-qt/qtbase with this:

-march=x86-64-v3

as you suggested, I can
confirm that it doesn’t work

It only works with no -march at all.

I see, that's too bad. Does x86-64-v2 fare any better? Maybe something up with AVX.

Either way that makes working around it difficult now, I have no real way to tell if the hardware is affected, at best =bdver4 is now more of a "guess" that it may be affected. In theory even the x86-64-v3 binary packages may be affected now (despite being fine for everyone else).

Perhaps not all bdver4 are affected too, so replacing bdver4 may be wrong for most users.

May need to keep the local-only package.env workaround, unsure if will do anything about this in the ebuild unless someone figures out the right fix.

Compiling dev-qt/qtbase with -march=x86-64-v2 works.
I use package.env to compile qtbase with the above.
So far in the forum only three, including me, have this problem. I see it the same way as you.
If only 3 are complaing so far it could only mean that for most people bdver4 doesn't give any problem.

[Ionen]

I have the growing suspicion that it may be a cpu bug if x86-64-v3 fails and -v2 works (when it *should* support v3 just fine). May only cause problems when specific conditions are met (much like the infamous znver1 bug which cause build failures only on specific packages and otherwise works just fine). With =native/bdver4 I thought it was something more specific that triggered a bug somewhere, but -v3 is commonly used.

So there may not be anything to fix in any of qtbase/gcc/kde/plasma, albeit I guess some rather unlikely UB somewhere is not entirely impossible.

If it is a cpu issue, not impossible that it can be mitigated by a firmware/microcode update though. Not that znver1 had much luck there.

On another note, it may be interesting to try emerging qtbase with FEATURES=test and see if anything fails when using x86-64-v3 (also check if everything passes with x86-64-v2), that could provide hints for smaller reproducer at least. If everything passes with either, could be interesting to know qtbase is not entirely broken too... maybe only with the specific usage that some software do.
Edit: I do assume some things do work right, otherwise its tools that use qtcore libraries would be broken and other packages fail to build, maybe it's only the qtgui components

[localtoast]

After an eternity of compiling, I'm back. It works! I can confirm that qtbase omitting march gives me a completely functioning Plasma 6 and sddm. Damn that feels good, I can use my main laptop again.

Compiling dev-qt/qtbase with -march=x86-64-v2 works.
I use package.env to compile qtbase with the above.
So far in the forum only three, including me, have this problem. I see it the same way as you.
If only 3 are complaing so far it could only mean that for most people bdver4 doesn't give any problem.

Thanks for trying this. I'll also rebuild qtbase with -v2 later on, at least then I'll have some arch optimization. First, though, I have to bask in having a working DE for a couple of hours at least.

I have the growing suspicion that it may be a cpu bug if x86-64-v3 fails and -v2 works (when it *should* support v3 just fine). May only cause problems when specific conditions are met (much like the infamous znver1 bug which cause build failures only on specific packages and otherwise works just fine). With =native/bdver4 I thought it was something more specific that triggered a bug somewhere, but -v3 is commonly used.

So there may not be anything to fix in any of qtbase/gcc/kde/plasma, albeit I guess some rather unlikely UB somewhere is not entirely impossible.

If it is a cpu issue, not impossible that it can be mitigated by a firmware/microcode update though. Not that znver1 had much luck there.

On another note, it may be interesting to try emerging qtbase with FEATURES=test and see if anything fails when using x86-64-v3 (also check if everything passes with x86-64-v2), that could provide hints for smaller reproducer at least. If everything passes with either, could be interesting to know qtbase is not entirely broken too... maybe only with the specific usage that some software do.
Edit: I do assume some things do work right, otherwise its tools that use qtcore libraries would be broken and other packages fail to build, maybe it's only the qtgui components

If I recall correctly, somewhere amongst all of the rebuilds and troubleshooting, I did emerge qtbase with USE="test" and -march=native. It didn't report any failures at build time as far as I know; the build didn't fail, and I didn't see any errors.

I'm still thinking this is worth at least filing a bug report with QT, even if they do nothing with it, just in the interest of documenting it.

I'm marking this solved. Thanks very much everyone for your help with this, there is no chance I would've fixed this by myself.

[Ionen]

If I recall correctly, somewhere amongst all of the rebuilds and troubleshooting, I did emerge qtbase with USE="test" and -march=native. It didn't report any failures at build time as far as I know; the build didn't fail, and I didn't see any errors..

USE=test does not run tests, it only builds them.

[localtoast]

If I recall correctly, somewhere amongst all of the rebuilds and troubleshooting, I did emerge qtbase with USE="test" and -march=native. It didn't report any failures at build time as far as I know; the build didn't fail, and I didn't see any errors..

USE=test does not run tests, it only builds them.

Oh. I thought it would run them at build time, before building.

[Ionen]

If I recall correctly, somewhere amongst all of the rebuilds and troubleshooting, I did emerge qtbase with USE="test" and -march=native. It didn't report any failures at build time as far as I know; the build didn't fail, and I didn't see any errors..

USE=test does not run tests, it only builds them.

Oh. I thought it would run them at build time, before building.

FEATURES=test is what makes portage run tests (after building, before installing, aborts on failure), and when that's set portage will automatically enable USE=test so tests get built or extra dependencies (like test runners) get pulled where needed. On its own USE=test is just wasteful.

(on a side-note, I don't recommend setting FEATURES=test unless actually need to test something, it can be rather messy if done globally and that's best left for gentoo's tinderboxes and arch testers to do )

[sam_]

I'm going to try look a bit more as I don't want to give up yet.

Can one of you (or ideally both of you) try FEATURES=test on qtbase with the bad -march and hopefully something small which is easier to analyse will fail?

The Qt memcpy & friends has had issues in the past so we might be able to at least play with macros there. We'll see.

[localtoast]

I will build it with FEATURES=test, but may take a couple of days to do so.

[localtoast]

Lot of stuff failed:

The following tests FAILED:
74 - tst_qsettings (Failed)
86 - tst_qsortfilterproxymodel (Failed)
95 - tst_qdatastream (Failed)
97 - tst_qtextstream (Failed)
219 - tst_qbackingstore (Failed)
233 - tst_qscreen (Failed)
235 - tst_qwindow (Failed)
238 - tst_qrasterwindow (Failed)
243 - tst_qguivariant (Failed)
247 - tst_qmouseevent_modal (Failed)
248 - tst_qtouchevent (Failed)
250 - tst_qpixmap (Failed)
251 - tst_qimage (Failed)
253 - tst_qmovie (Failed)
254 - tst_qpicture (Failed)
256 - tst_qicon (Failed)
260 - tst_qbrush (Failed)
272 - tst_qstatictext (Failed)
276 - tst_qtextdocumentfragment (Failed)
277 - tst_qtextdocumentlayout (Failed)
279 - tst_qtextimagehandler (Failed)
282 - tst_qtexttable (Failed)
284 - tst_qtextdocument (Failed)
292 - tst_qstandarditem (Failed)
294 - tst_qfilesystemmodel (Failed)
296 - tst_qrhi (Failed)
324 - tst_qabstractprintdialog (Failed)
340 - tst_qsqlrelationaldelegate (Failed)
341 - tst_qcolordialog (Failed)
342 - tst_qdialog (Failed)
344 - tst_qinputdialog (Failed)
345 - tst_qprogressdialog (Failed)
346 - tst_qwizard (Failed)
347 - tst_qmessagebox (Failed)
348 - tst_qgraphicseffect (Failed)
349 - tst_qpixmapfilter (Failed)
350 - tst_qgraphicseffectsource (Failed)
351 - tst_qgraphicsgridlayout (Failed)
353 - tst_qgraphicslayout (Failed)
355 - tst_qgraphicslinearlayout (Failed)
357 - tst_qgraphicspixmapitem (Failed)
360 - tst_qgraphicsproxywidget (Failed)
361 - tst_qgraphicswidget (Failed)
362 - tst_qabstractitemview (Failed)
363 - tst_qdatawidgetmapper (Failed)
365 - tst_qheaderview (Failed)
366 - tst_qitemdelegate (Failed)
368 - tst_qitemview (Failed)
369 - tst_qlistview (Failed)
370 - tst_qtableview (Failed)
371 - tst_qtablewidget (Failed)
372 - tst_qtreeview (Failed)
373 - tst_qtreewidget (Failed)
375 - tst_qboxlayout (Failed)
376 - tst_qformlayout (Failed)
377 - tst_qgridlayout (Failed)
378 - tst_qlayout (Failed)
379 - tst_qstackedlayout (Failed)
380 - tst_qtooltip (Failed)
381 - tst_qwidget_window (Failed)
383 - tst_qwidgetrepaintmanager (Failed)
385 - tst_qwindowcontainer (Failed)
387 - tst_qgesturerecognizer (Failed)
388 - tst_qwidget (Failed)
389 - tst_qshortcut (Failed)
391 - tst_qaction (Failed)
393 - tst_qwidgetaction (Failed)
395 - tst_qcompleter (Failed)
396 - tst_qscroller (Failed)
397 - tst_qsystemtrayicon (Failed)
398 - tst_qabstractbutton (Failed)
399 - tst_qabstractscrollarea (Failed)
401 - tst_qbuttongroup (Failed)
402 - tst_qcalendarwidget (Failed)
404 - tst_qcommandlinkbutton (Failed)
405 - tst_qdatetimeedit (Failed)
407 - tst_qdialogbuttonbox (Failed)
408 - tst_qdockwidget (Failed)
409 - tst_qdoublespinbox (Failed)
411 - tst_qframe (Failed)
412 - tst_qgroupbox (Failed)
413 - tst_qlabel (Failed)
415 - tst_qmdisubwindow (Failed)
416 - tst_qplaintextedit (Failed)
417 - tst_qprogressbar (Failed)
418 - tst_qpushbutton (Failed)
419 - tst_qradiobutton (Failed)
420 - tst_qscrollarea (Failed)
421 - tst_qscrollbar (Failed)
422 - tst_qsizegrip (Failed)
424 - tst_qspinbox (Failed)
425 - tst_qsplashscreen (Failed)
426 - tst_qsplitter (Failed)
427 - tst_qstackedwidget (Failed)
428 - tst_qstatusbar (Failed)
429 - tst_qtabbar (Failed)
430 - tst_qtabwidget (Failed)
431 - tst_qtextbrowser (Failed)
433 - tst_qtoolbutton (Failed)
435 - tst_qmenu (Failed)
436 - tst_qmdiarea (Failed)
437 - tst_qmenubar (Failed)
440 - tst_gestures (Failed)
441 - tst_languagechange (Failed)
442 - tst_qfocusevent (Failed)
446 - tst_qaccessibility (Failed)

Complete (large) test log is here: http://0x0.st/X3hf.log

This was with -O2 -march=native -mtune=native