Closed Bug 1175546 (gcc-4.8) Opened 9 years ago Closed 8 years ago

Update linux builds to require GCC 4.8

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(firefox41 affected, firefox48 fixed)

RESOLVED FIXED
mozilla48
Tracking Status
firefox41 --- affected
firefox48 --- fixed

People

(Reporter: jib, Assigned: glandium)

References

Details

Attachments

(1 file)

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 :-)
See Also: → 1136040
Blocks: 1073319
No longer blocks: 1073319
glandium, from a distro compat perspective, can we require gcc 4.8 for Gecko 47?  What about 4.9?
Flags: needinfo?(mh+mozilla)
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.
Flags: needinfo?(mh+mozilla)
(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?)
No longer blocks: gcc-4.9
Alias: gcc-4.8
Depends on: 1243331
(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
I already tried and filed bug 1243331
Depends on: 1243604
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.
Depends on: 1246772
Depends on: 1150338
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?
Attachment #8729288 - Flags: review?(nfroyd) → review+
https://hg.mozilla.org/mozilla-central/rev/2d59367c985a
https://hg.mozilla.org/mozilla-central/rev/17eabd8512ff
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
Depends on: 1261264
Assignee: nobody → salva
Assignee: salva → nobody
Assignee: nobody → mh+mozilla
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?
Flags: needinfo?(mh+mozilla)
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.
Flags: needinfo?(mh+mozilla)
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.
No longer blocks: 1280295
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: