Project:Toolchain/sys-devel/gcc

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.

Snapshots

 * We try to package the weekly snapshots published by the GCC developers.
 * This matches what e.g. opensuse 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 and 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. ) 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. https://gcc.gnu.org/gcc-13/porting_to.html.
 * 2) Update Project:Toolchain/Porting notes with a new page.
 * 3) Create a new folder in , 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

 * 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!)
 * 3) Daily drive it if possible.
 * 4) Perform regular  runs (the more packages installed & the less common, the better!) to build failures initially and later, regressions.
 * 5) Consider doing a   (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.

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