From Bug 1029245 comment 8: gcc 4.8 has bug-fixes, among which are (of interest to me): - No longer erroneously complains about calling static member functions from lambdas when 'this' is not captured [1]. I ran into this problem last week in a patch (workaround is a file-scope stub). [1] http://stackoverflow.com/questions/4940259/lambdas-require-capturing-this-to-call-static-member-function

Bob went through the procedure of dropping support of gcc < 4.7. He probably has something to say about all he went through for that. Speaking with my Debian maintainer hat, dropping gcc 4.7 support means dropping support for gecko-based packages on wheezy, which is still supported for a year at least. Although, the timing is kind of good because the drop of gcc 4.7 would only really matter for Debian for the next esr (45?), which is about in a year. OTOH, that increases the chances of something relying on that particular bug being fixed slipping through to 38esr through backports (but that would be caught on automation, since that uses gcc 4.7, that would just make backporters life harder than it already is).

I think most of the discussions around moving to a minimum of gcc-4.7 happened on bug 1136040. There were some on dev-platform over moving to 4.8 as well. Mainly in https://groups.google.com/forum/#!searchin/mozilla.dev.platform/gcc-4.6/mozilla.dev.platform/ZeUgSSGHBPk/73MEE4sKLagJ I don't think that moving to 4.8 gives us any new language features until we can also drop Visual Studio 2013 and move to VS2015. That isn't even released yet, so I suspect that is going to be a while away. As far as I remember fixes in 4.8 (that mean we don't have to use workarounds) weren't really discussed. So, I guess they bolster the argument for moving to 4.8 now. Although I suppose it depends on how many of these fixes there are and how painful the workarounds are. Anyway round, I think we ought to go back round the Linux package maintainers and see if they see any major problems. I'd be happy to do this when the time comes. After going through my emails with various Linux package maintainers and looking at current package information that I can find: * openSUSE - It looks like 4.8 is already available on supported versions. * SLES - Petr Cerny has confirmed that on older systems they already maintain a special stack of packages for building Firefox, which contains gcc-4.7. From his email it didn't sound like moving to 4.8 would be a major problem, though we should confirm that. * Ubuntu - Ubuntu 12.04 LTS is still on gcc-4.6.3, however they built Firefox 38 (which required 4.7) with a stand-alone gcc-mozilla package, which was 4.8.4. Ubuntu 14.04 LTS is already on 4.8.2. * RedHat - RHEL5 and RHEL6 are on 4.4, I'm not sure if there is an official Fx38 package for RHEL5 or 6, but it looks like there is one for CentOS 5.11 (which is based on RHEL5.11). Not sure what that is compiled with, but from what I can tell even on RHEL7 gcc-4.7.2 is the latest. * Debian - see comment 1 :-)

glandium, from a distro compat perspective, can we require gcc 4.8 for Gecko 47? What about 4.9?

See comment 1 and 2 for 4.8. 4.9 is fine-ish for Debian, it would mean dropping support for oldstable for the next-next esr (52). Can't say for other distros.

(In reply to Mike Hommey [:glandium] from comment #4) > Can't say for other distros. (I mean, without asking them)

Hmm, if I'm reading comment 2 correctly, the only distro in question in Debian right? Is there anything else that needs to be checked?

Oh, I guess there might be distors other than in comment 2 that we're worried about? I'm not really sure what the usual process is like? (Would we be the only software that drops support for old gcc releases? Couldn't distors backport newer compilers and use them for applications that need them? I don't know, maybe that's not how things work?)

(In reply to :Ehsan Akhgari from comment #7) > Oh, I guess there might be distors other than in comment 2 that we're > worried about? I'm not really sure what the usual process is like? > > (Would we be the only software that drops support for old gcc releases? > Couldn't distors backport newer compilers and use them for applications that > need them? I don't know, maybe that's not how things work?) Some do, some don't. Debian might, but it's not a given. Anyways, it's not a problem for 4.8, we already agreed to bump to 4.8 after 45. 4.9 has its own bug, btw: bug 1029245. Anyways, I built GCC 4.8.5 + binutils 2.25.1 on taskcluster (yay) and uploaded it to tooltool. Here is the manifest: [ { "size": 81065660, "visibility": "public", "digest": "db26f498ab56a3b5c65d7cda290cbb74174af9f2d021ca9c158f53b0382924ccf5ed9638d41eef449434aa9383a9113994d9729d9dd910321d1f35f9411eae38", "algorithm": "sha512", "filename": "gcc.tar.xz" } ] It was built from: https://hg.mozilla.org/try/rev/1c894be28d21

Let's see what happens! <https://treeherder.mozilla.org/#/jobs?repo=try&revision=f75d8b38d51a>

I already tried and filed bug 1243331

Yeah, so another issue uncovered in <https://treeherder.mozilla.org/#/jobs?repo=try&revision=32ede4fb78e3> is that we don't pass -Wno-error=maybe-uninitialized down to NSS and there is a new instance of that warning which is treated as an error. :( Not sure what is the best way of fixing that. Also seems like there is some miscompilation going on in mochitest-debug-7 x86. Funtimes.

(In reply to Bob Owen (:bobowen) from comment #2) > * RedHat - RHEL5 and RHEL6 are on 4.4, I'm not sure if there is an official > Fx38 package for RHEL5 or 6, but it looks like there is one for CentOS 5.11 > (which is based on RHEL5.11). Not sure what that is compiled with, but from > what I can tell even on RHEL7 gcc-4.7.2 is the latest. Red Hat provides official ESR packages for all supported RHEL releases. The latest package here is ESR 38.6 and we're going to update to 45. We build the FF package with bundled gcc 4.8 which also available by Dev Toolset package for RHEL.

FWIW, we keep running into this GCC compiler bug related to enum classes with byte-sized storage (bug 1243810 and bug 1143966 for instance): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64037 It causes weird bugs and crashes and has been fixed in 4.8.5 and 4.9.3.

(In reply to Jan de Mooij [:jandem] from comment #13) > FWIW, we keep running into this GCC compiler bug related to enum classes > with byte-sized storage (bug 1243810 and bug 1143966 for instance): > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64037 > > It causes weird bugs and crashes and has been fixed in 4.8.5 and 4.9.3. This is 4.8.5...

(In reply to :Ehsan Akhgari from comment #14) > > It causes weird bugs and crashes and has been fixed in 4.8.5 and 4.9.3. > > This is 4.8.5... It keeps biting us with GCC 4.7 and I really want us to update to 4.8.5 to avoid these issues. I didn't mean to imply this is related to the miscompilation you saw on Try. Sorry if it sounded that way.

Review commit: https://reviewboard.mozilla.org/r/39343/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/39343/

Comment on attachment 8729288 [details] MozReview Request: Bug 1175546 - Update GCC to 4.8.5 and bump minimum GCC version required to build https://reviewboard.mozilla.org/r/39343/#review36159 This works with hazard and spidermonkey builds, too? Neat. Can you also fix mfbt/Compiler.h to check for the correct version of GCC as well?

https://hg.mozilla.org/mozilla-central/rev/2d59367c985a https://hg.mozilla.org/mozilla-central/rev/17eabd8512ff

glandium, would it be okay to require 4.8.5 instead of 4.8.0? Asking because 4.8.5 has the fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64037 We keep hitting that bug in SpiderMonkey unfortunately. Today it's bug 1298350. GCC 4.9.0-4.9.2 also has the bug, but due to other compiler changes it may not affect the same code, so fixing it for 4.8 would still be a win I think. Maybe we can also block 4.9.0-4.9.2?

We generally don't explicitly reject compilers that miscompile our code. The latest example of this is GCC 6. We haven't excluded it, despite it breaking Firefox big time with its new optimizations.

Note that there are compiler flags that will break Firefox big time as well (with any version of the compiler), and we don't reject them either. Same reasons.