Changes/GCC49

From FedoraProject

Jump to: navigation, search

Contents

GCC49

Summary

Switch GCC in Fedora 21 to 4.9.x, rebuild all packages with it.

Owner

Current status

Detailed Description

GCC 4.9.0 is currently in stage4, in prerelease state with only regression bugfixes and documentation fixes allowed. The release will happen probably in the first half of April. Marek Polacek has performed a test mass rebuild on x86_64 with gcc-4.9.0-0.*.fc21, most packages have built successfully, others have failed to rebuild also with gcc 4.8.x, for the remaining packages most of the needed changes are now tracked in http://gcc.gnu.org/gcc-4.9/porting_to.html or, if it were bugs on the gcc side, have been fixed in the mean time. GCC 4.9.0 prereleases have so far been built as scratch packages, http://koji.fedoraproject.org/scratch/jakub/task_6667028/ (and similarly for ppc* and s390* secondary architectures). Other distributions have performed test mass rebuilds on other architectures (i?86, s390x, arm).

Benefit to Fedora

See http://gcc.gnu.org/gcc-4.9/changes.html for the list of changes.

Scope

All packages should be rebuilt with the new gcc once it hits f21.

  • Proposal owners:

Build gcc in f21, rebuild packages that have direct dependencies on exact gcc version (libtool, llvm, gcc-python-plugin).

  • Other developers: First few days/weeks just voluntary rebuilds using the new system gcc, if things fail, look at http://gcc.gnu.org/gcc-4.9/porting_to.html and fix bugs in packages or, if there is a gcc bug or suspected gcc bug, analyze and report.
  • Release engineering: Organize a mass rebuild
  • Policies and guidelines: No policies need to be changed

Upgrade/compatibility impact

No impact

How To Test

GCC has its own testsuite, which is run during the package build, plus many other packages with automated tests also help to test the new gcc.

User Experience

Users will be able to see compiled code improvements and use the newly added features, such as improved C++11 and added partial C++14 support, OpenMP 4.0 support, improved vectorization support, etc. Developers will notice a newer compiler, and might need to adjust their codebases acording to http://gcc.gnu.org/gcc-4.9/porting_to.html, or, if they detect a GCC bug, report it.

Dependencies

libtool, dragonegg, gcc-python-plugin, llvm depend on exact gcc version, those need to be rebuilt.

Contingency Plan

If bugs are discovered, I'd appreciate help from the package owners in preparing self-contained testcases to speed up analysis and fixing the bugs. Don't have time to debug issues in 12000+ packages, especially when in many cases it could be caused by undefined code in the packages etc. I don't expect we'll have to fall back to the older gcc, we've never had to do it in the past, but worst case we can mass rebuild everything with older gcc again.

  • Contingency mechanism: Revert to older gcc, mass rebuild everything again
  • Contingency deadline: Before release
  • Blocks release? Yes
  • Blocks product? No

Documentation

http://gcc.gnu.org/gcc-4.9/

Release Notes

Fedora 21 comes with GCC 4.9.0 as primary compiler, see http://gcc.gnu.org/gcc-4.9/changes.html for user visible changes in it.