Closed Bug 902104 Opened 6 years ago Closed 6 years ago

switch linux builds to GCC 4.7.3

Categories

(Firefox Build System :: General, defect)

defect
Not set

Tracking

(firefox24 fixed, firefox25 fixed, firefox26 fixed)

RESOLVED FIXED
mozilla26
Tracking Status
firefox24 --- fixed
firefox25 --- fixed
firefox26 --- fixed

People

(Reporter: froydnj, Assigned: froydnj)

References

Details

Attachments

(2 files)

No description provided.
As https://bugzilla.mozilla.org/show_bug.cgi?id=900549#c0 suggests, there's some
GCC 4.7.2-specific bustage that's been fixed in 4.7.3, along with a decently long
list of fixes:

http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.7.3

A number of these are in the C++ front-end, which is important to us as we start to
use more and more C++ features.

The try run with an updated mozconfig seems to be green, and the breakage referenced
in bug 900549 has been fixed too:

https://tbpl.mozilla.org/?tree=Try&rev=ef8bb9007df7
Attachment #786438 - Flags: review?(gps)
Can you do a PGO push so we can verify this doesn't regress linker memory usage or build times? I just don't want any surprises when this lands.
(In reply to Gregory Szorc [:gps] from comment #2)
> Can you do a PGO push so we can verify this doesn't regress linker memory
> usage or build times? I just don't want any surprises when this lands.

Sure: https://tbpl.mozilla.org/?tree=Try&rev=4d23770fe5f1
And one that actually includes Talos (and one more patch): https://tbpl.mozilla.org/?tree=Try&rev=e97740a1671b
Looks like the PGO builds are busted, according to those Try links.  Something goes wrong linking trace-malloc in debug mode, and we can't find the __gcov* symbols.  Need to look into that.
(In reply to Nathan Froyd (:froydnj) from comment #4)
> Looks like the PGO builds are busted, according to those Try links. 
> Something goes wrong linking trace-malloc in debug mode, and we can't find
> the __gcov* symbols.  Need to look into that.

Since those are debug PGO builds and we never do those, they are a non-issue.  Everything looks good.
Comment on attachment 786438 [details] [diff] [review]
upgrade to GCC 4.7.3

Review of attachment 786438 [details] [diff] [review]:
-----------------------------------------------------------------

PGO times are in the same ballpark, so I'm not too worried. And, it's the beginning of a release cycle. Land it!
Attachment #786438 - Flags: review?(gps) → review+
The spidermonkey builds are going to break at some point without a corresponding build update.
Attachment #787490 - Flags: review?(bhearsum)
Comment on attachment 787490 [details] [diff] [review]
update spidermonkey builds to gcc 4.7.3

Aha, bhearsum is on PTO.  Maybe Callek feels comfortable reviewing this?
Attachment #787490 - Flags: review?(bhearsum) → review?(bugspam.Callek)
Pushed the mozilla side of things; I think we can actually work around the spidermonkey bits in other places, so it doesn't have to go in right away.

https://hg.mozilla.org/integration/mozilla-inbound/rev/681cd35e0e5e
https://hg.mozilla.org/mozilla-central/rev/681cd35e0e5e
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
Assignee: nobody → froydnj
Comment on attachment 786438 [details] [diff] [review]
upgrade to GCC 4.7.3

[Approval Request Comment]
Bug caused by (feature/regressing bug #): None.
User impact if declined: Sheriff pain in dealing with PGO crashes for the next ESR cycle.
Testing completed (on m-c, etc.): On m-c for most of the 26 cycle thus far.
Risk to taking this patch (and alternatives if risky): Minimal.
String or IDL/UUID changes made by this patch: None.

Bug 873667 is about intermittent crashes during Linux PGO compilations.  Since this patch landed, we haven't seen *compiler* crashes; our theory is that upgrading the compiler has fixed the compiler crashes, though it hasn't fixed the assembler crashes that still occur.  We'd therefore like to get this patch uplifted to aurora and beta so that ESR builds can be less crashy.
Attachment #786438 - Flags: approval-mozilla-beta?
Attachment #786438 - Flags: approval-mozilla-aurora?
Assignee: froydnj → nfroyd
I am needinfo'ing releng(aki,nthomas) to ensure they are aware of this change and confirm this will not impact them in anyway in build generation(keeping in mind issues with Fx24 Beta1 due to build config, compiler changes..)
Flags: needinfo?(nthomas)
Flags: needinfo?(aki)
I think this will be ok for beta, since we have the repacks pointing at the in-tree mozconfigs, and it appears we have mock set up to install 4.7.3 in parallel.

Source builds are still pointing at http://hg.mozilla.org/build/buildbot-configs/file/a2a551e2c582/mozilla2/linux/mozilla-beta/release/mozconfig which should probably be updated at the same time.

I would tend to avoid uplifting to release unless this has dot-release implications.
Flags: needinfo?(aki)
(In reply to Aki Sasaki [:aki] from comment #13)
> I think this will be ok for beta, since we have the repacks pointing at the
> in-tree mozconfigs, and it appears we have mock set up to install 4.7.3 in
> parallel.
> 
> Source builds are still pointing at
> http://hg.mozilla.org/build/buildbot-configs/file/a2a551e2c582/mozilla2/
> linux/mozilla-beta/release/mozconfig which should probably be updated at the
> same time.
> 
> I would tend to avoid uplifting to release unless this has dot-release
> implications.

Thanks ! The approvals are only for beta/aurora so no impact on release and looks like we are good for uplift here.
Comment on attachment 786438 [details] [diff] [review]
upgrade to GCC 4.7.3

Request to help land on beta asap so this can go can get into today's beta going to build shortly.
Attachment #786438 - Flags: approval-mozilla-beta?
Attachment #786438 - Flags: approval-mozilla-beta+
Attachment #786438 - Flags: approval-mozilla-aurora?
Attachment #786438 - Flags: approval-mozilla-aurora+
Why are we changing the toolchain in the middle of a release? That seems unnecessarily risky to me, even if the new version is purportedly better.
Oh, bleh.  Aurora and beta are *both* still on 4.5.0.  That does seem a little iffy for uplift, and might require more changes than tweaking the mozconfig.  Not something to be done quickly...
no, they're gcc 4.7.2

tbsaunde@iceball:/src/moz3$ git show origin/aurora:build/unix/mozconfig.linux
. "$topsrcdir/build/mozconfig.common"

CC="/tools/gcc-4.7.2-0moz1/bin/gcc"
CXX="/tools/gcc-4.7.2-0moz1/bin/g++"

ac_add_options --enable-elf-hack

ac_add_options --enable-stdcxx-compat
tbsaunde@iceball:/src/moz3$ git show origin/beta:build/unix/mozconfig.linux
. "$topsrcdir/build/mozconfig.common"

CC="/tools/gcc-4.7.2-0moz1/bin/gcc"
CXX="/tools/gcc-4.7.2-0moz1/bin/g++"

ac_add_options --enable-elf-hack
tbsaunde@iceball:/src/moz3$
(In reply to Nathan Froyd (:froydnj) from comment #17)
> Oh, bleh.  Aurora and beta are *both* still on 4.5.0.  That does seem a
> little iffy for uplift, and might require more changes than tweaking the
> mozconfig.  Not something to be done quickly...

Wait, no.  |hg pull -u| just didn't update across branches.

(In reply to Gregory Szorc [:gps] from comment #16)
> Why are we changing the toolchain in the middle of a release? That seems
> unnecessarily risky to me, even if the new version is purportedly better.

GCC point releases are (usually) pretty safe, since they are only bugfixes.  I wouldn't have requested uplifted for major version upgrades.
We need some way to make sure that buildbot-configs/mozilla2/linux/mozilla-release/release/mozconfig is also updated when Firefox 24 merges there. I'll make a note in bug 902293 since that's already tracking some other changes.
buildbot-configs changes are in production
Comment on attachment 787490 [details] [diff] [review]
update spidermonkey builds to gcc 4.7.3

Review of attachment 787490 [details] [diff] [review]:
-----------------------------------------------------------------

sorry that this languished, didn't notice it on closed bug. feel free to land if its still relevant
Attachment #787490 - Flags: review?(bugspam.Callek) → review+
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.