Description of problem: GCC 8 miscompiles the GN build tool (used by Chromium and QtWebEngine) on x86_64, see https://bugs.chromium.org/p/chromium/issues/detail?id=812877#c10 for details. Version-Release number of selected component (if applicable): gcc-8.0.1-0.13.fc28 How reproducible: Always Steps to Reproduce: 1. Try to build chromium or qt5-qtwebengine in Rawhide. Actual results: The build fails due to a crash in gn. (Sometimes it segfaults, sometimes it asserts, but it always ends up crashing one way or the other.) Expected results: The build succeeds. Additional info: The build worked with GCC 7. See https://bugs.chromium.org/p/chromium/issues/detail?id=812877#c10 for a comparison of the generated assembly code. I am classifying this as urgent because it prevents fixing broken dependencies in QtWebEngine in Rawhide, and also blocks pushing out the 5.10.1 security update due to upgrade path concerns.
A workaround for now would be to build with -fabi-version=11.
I can confirm using -fabi-version=11 seems to help qt5-qtwebengine get past where it was crashing originally
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle. Changing version to '28'.
I'd hope this would be fixed by http://gcc.gnu.org/PR84502 fix. Now, the question is how to determine what all packages besides these are affected. At least in make-check-c++, it seems finalize_type_size is always called on TYPE_MAIN_VARIANT, so the || type != TYPE_MAIN_VARIANT (type) is there perhaps useless or just for other frontends. If a variant type is created after the main variant has been finalized using finalize_type_size, all should be fine, TYPE_EMPTY_P is copied to the new type together with all the other flags. The only problem is if the type variants are created before the type is finalized, and the uses of TYPE_EMPTY_P in calls.c, function.c, tree.c, targhooks.c and config/i386/i386.c don't use the main variant of the type. So, one way to determine that would be to augment the TYPE_EMPTY_P uses in the above 5 files and check if !TYPE_EMPTY_P (something) && TYPE_EMPTY_P (TYPE_MAIN_VARIANT (something)). Another would be hack up a -fcompare-debug like compilation mode where everything would be compiled twice, in both cases without the finalize_type_size fix, once testing TYPE_EMPTY_P (something) and once TYPE_EMPTY_P (TYPE_MAIN_VARIANT (something)) and see if the assembly or final dump like compare debug differ.
Can you please try if gcc-8.0.1-0.16.fc28 fixes this issue?
Should be fixed in gcc-8.0.1-0.16.fc28.
Trying a qt5-qtwebengine Rawhide build without the workaround now: https://koji.fedoraproject.org/koji/taskinfo?taskID=25261803 If it succeeds, I'll also build that for F28.
Looks like this is working, though the build is still running. F28 build: https://koji.fedoraproject.org/koji/taskinfo?taskID=25262473
Builds fine on x86_64 on both F28 and Rawhide without the -fabi-version=11 workaround now. So I can confirm that this bug is fixed.