From Gentoo Wiki
Jump to:navigation Jump to:search
Warning, this page is a work in progress by sam (talk | contribs). Treat its contents with caution.

Release cycle

  • Upstream maintains approximately 3 branches at a time (e.g. 10/11/12).
  • The last version of a branch is usually X.5, e.g. GCC 9.5. Upstream then immediately close the relevant branch (e.g. releases/gcc-9) and it is no longer used for backports.
  • When a new major GCC version enters Stage 4, the Gentoo Toolchain project begins testing (or steps up efforts if they already began) with building large amounts of the tree. Request tinderboxing if possible.
    • At this point, it's encouraged that developers with backups consider converting their experimental systems to the new, unreleased version.


  • We try to package the weekly snapshots published by the GCC developers.
  • Upstream are quite rigid about releasing once per year for each release series (with the exception of the first two releases, which happen about 2-4 months apart). Serious regressions are often fixed after releases and by using snapshots, we pick these up quickly.
  • We don't therefore worry about keeping the last "real" releases in tree. There's no real benefit from using them apart from making people feel better.
  • This matches what e.g. opensuse (+ fedora/debian/ubuntu) does and it allows us to easily pick up fixes rather than trying to delicately cherry-pick only a handful and possibly missing dependent commits as a result (GCC doesn't at present use 'Fixes' very often in commit messages, so it's not always easy to establish).
  • Don't keyword every snapshot.
  • Snapshots should usually start off unkeyworded even if the intent is to keyword-and-later-stable it.
  • The snapshots correspond to a particular release branch, except for the latest unreleased version, and are safe to use.
    • GCC doesn't make frequent stable releases because of the work involved on their end and expect distributions to pull from these branches.

Procedure for new major versions

  1. File a tracker bug (see e.g. bug #865117) called "sys-devel/gcc-13 porting" and add 'gcc-13' to the Alias field (replace version as necessary). Link to the relevant GCC porting page in the bug, e.g.
  2. Update Project:Toolchain/Porting notes with a new page.
  3. Create a new folder in gcc-patches.git, copying from the last version. Test/rebase as needed. Use the live ebuilds with an override to test a local gcc-patches repo to avoid committing junk which doesn't apply.

Testing new major versions

We appreciate testing from keen users, but please be careful to not report bugs upstream without running it by someone else first. Ideally please file a Gentoo bug first, clearly noting which GCC is being used, and it can be taken from there.
  1. Usually wait a while until GCC reaches Stage 4 (subscribe to the GCC mailing list if haven't already)
  2. Once GCC reaches Stage 4, consider building testing systems with it (as long as there's backups!)
    1. Daily drive it if possible.
    2. Perform regular emerge -ev @world runs (the more packages installed & the less common, the better!) to build failures initially and later, regressions.
    3. Consider doing a FEATURES=test (consider skipping dev-python/*, dev-perl/* etc via package.env) build with the previous GCC version, noting the test failures which occur with the known-working version (and reporting any bugs), then do it again with the new GCC version to see if anything broke. Report bugs and investigate. Failures are likely bugs in the programs (probably UB) but there's a chance of a compiler bug too.


The following is a snippet to pick up the snapshots in each slot even if unkeyworded:

FILE /etc/portage/package.accept_keywords/gcc
# Get the latest version of this from
<sys-devel/gcc-11.5.9999:11 **
<sys-devel/gcc-12.4.9999:12 **
<sys-devel/gcc-13.3.9999:13 **
<sys-devel/gcc- **

External links