Getting ready for GCC 5.1
Confusingly, GCC has a new, weird, version scheme. The first release of GCC 5 will be 5.1. It is due soon (next week). For that reason, and because it's better to find compiler bugs before it's released, I started looking into building Firefox with it.
The first round of builds I did was with 5-20150405. That got me to find a small bunch of issues:
- The new libstdc++ ABI breaks our compatibility with older libstdc++, which we've been going into great length to keep. Fortunately, it's still possible to build with some level of compatibility by compiling with
-D_GLIBCXX_USE_CXX11_ABI=0. - Some build failure in pkix gtests because of unused gtest-generated variables in an anonymous namespace.
- New false positive hits on
-Warray-bounds, which, with-Werror, led the build to fail. - New libstdc++ compatibility issue that prevented from running elfhack during the build (we don't set
LD_LIBRARY_PATHto use the libstdc++ that comes with GCC). Incidentally, I found that the check to ensure we don't introduce dependencies on unwanted symbols from libstdc++ has been broken (by myself) for a few months. Fortunately, nothing slipped in between. - An Internal Compiler Error (ICE) on
--enable-debugbuilds, which turned out to be already fixed.
So that got me to do a second round with the first 5.1 RC, which had the fix for that ICE.
With all the above fixed, I could finally get builds out of try, and tests running, which revealed two more issues:
- Another (quickly fixed) Internal Compiler Error on 32-bits PGO builds (but only for a nightly setup, with
--enable-profiling, not for a release setup, which doesn't have it). - JS engine assertions during some JIT tests on 64-bits builds (with or without PGO), which Dan Gohman kindly tracked down and reduced to a small test case allowing to file a GCC bug and bisect to pinpoint at the GCC upstream commit that broke it (yay
git bisect runon a 36-CPU EC2 instance).
Preliminary results are promising, with benchmarks improving up to 16%, but the comparison wasn't entirely fair, because they compared GCC 4.8 builds with frame pointers and JS engine diagnostics to GCC 5.1 builds without.
I'll also give a spin to LTO, possibly finding more GCC bugs in the process.
2015-04-15 03:59:43+0900
You can leave a response, or trackback from your own site.
2015-04-15 19:09:03+0900
What are you expecting from / looking forward to w/ gcc5? Is it better execution speed or C++11 support (are you using this in FFx already)?
Or just because it’s going to be the standard 2yrs from now?
Also I wanted to thank you for your posts. You don’t get many comments, but that doesn’t mean no one’s reading. Obviously. ;-)
2015-04-23 04:48:25+0900
@AnimalFriend, I was interested in the presumed LTO improvements. But mostly, my main focus was just ensuring that GCC 5.1 was not going to fail to build Firefox properly, which, as it happens, it was going to.
2015-04-28 16:08:13+0900
I hope we will get the improvements for LTO, too. I sent you email concerning the talos benchmarks.