• ## page was renamed from MichaelHope/Sandbox/MakingChanges

Making Changes

This page documents how we handle making changes to Linaro GCC including the steps and people involved.

There are a number of different types of change:

  • New feature
  • Third-party supplied feature
  • Bug fix
  • Linaro specific fix

A new feature is developed on mainline, committed, then backported to Linaro GCC. A third-party supplied feature is developed somewhere else, lands in Linaro GCC first, and later lands on mainline. A bug fix is developed on mainline, then backported to Linaro GCC. A Linaro specific fix occurs in Linaro GCC due to our particular set of patches, and is developed on and stays in Linaro GCC.

Note that new features are never developed in Linaro GCC.

Supported architectures

Our main architectures are:

  • ARMv7 in Thumb-2 NEON Cortex-A9 mode
  • i686
  • x86_64
  • ARMv7 in Thumb-2 VFPv3-D16 Cortex-A8 mode

Any change should be tested at least on an x86 and ARM. See WorkingGroups/ToolChain/Hardware for ARM hardware you can use.

The cbuild automatic builder builds for all of the above and might expand to include:

  • ARMv5 in ARM soft float mode
  • ARMv4T in ARM soft float mode
  • Profile guided bootstrap
  • -Os bootstrap


If you're a developer, do the following:

For mainline changes, use the normal mainline rules:

  • Develop against the latest SVN

  • Test on appropriate common platforms
  • Send a patch up to gcc-patches for review

  • Re-work as needed
  • Once accepted, commit to SVN

cbuild monitors mainline and builds trunk, the 4.5 branch, and the 4.6 branch once a week on our supported architectures. Results are sent to gcc-testresults.

For trivial changes to Linaro GCC:

  • Develop against bzr tip

  • Test on appropriate common platforms
  • Optionally, send a patch to linaro-toolchain for review

  • Commit directly to bzr

cbuild will pick up any commits and build them on our supported platforms. Results are sent to linaro-toolchain-builds.

For non-trivial changes or if you'd like deeper review:

  • Branch bzr tip into a feature branch
  • Develop in this feature branch
  • Test on appropriate common platforms
  • Push the branch to Launchpad
  • Submit a merge request
  • Once accepted, merge into bzr tip

cbuild will pick up the merge request and build the feature branch on our supported architectures. Results are attached to the merge request. It will also build the final version that gets merged into tip.


Most features are developed on mainline. Any such feature should be backported to Linaro GCC 4.6 and, if practical, to Linaro GCC 4.5. As the change has already gone through review, you can decide to skip review within Linaro and commit directly to tip or merge directly from a feature branch.


Most changes are reviewed on mainline by the greater GCC community. Use your discretion on backports or Linaro specific changes and decide if a review is worthwhile. If it is, send off a merge request. The merge request will go to everyone in ~linaro-toolchain-dev and should be reviewed up on Launchpad. Anyone can review a change, but failing that one person is rostered on each week and is responsible for getting any new merge requests reviewed.

See the Linaro Events calendar for the current roster.

The review does not need to be deep but should cover the basics of style, having a test case, having all the needed files, being an accurate backport of upstream, and basic correctness.

Automatic Builds

Michael runs an automatic build system that checks out and does a bootstrap build of GCC. The tool is called cbuild and is hosted on Launchpad at:

We have enough hardware that any commit or merge request should be built within two working days.

Build results end up at:

such as lp:gcc-linaro/4.5 at revision 99475:

or michaelh1's 'optspace' feature branch:

Builds of mainline also end up there.

The results of each build and each host end up in the logs directory such as:

Each build has a directory named something like armv7l-maverick-cbuild79-carina5-cortexa8r1 where:

  • armv7l is the architecture
  • maverick is the distribution it was built on
  • cbuild79 gives the revision number of the cbuild scripts used
  • carina5 is the host name
  • cortexa8r1 is the particular configuration

Each log directory contains useful outputs:

  • host.txt has a summary of the host such as tool versions, ulimit, and processor information

  • gcc-configure.txt is the configure log. The first line has the flags passed to configure such as --prefix=... --enable-languages=c,c++,objc,obj-c++,fortran,lto --with-mode=thumb --with-arch=armv7-a --with-float=softfp --with-fpu=vfpv3-d16

  • gcc-build.txt is the build log

  • gcc-testsuite.txt is the results of running the testsuite

  • *.sum.xz are the detailed testsuite logs

  • gcc-run.txt has the final size of all executables. More useful in benchmarks.

You can see where your job is at and what machines are running at the scheduler:

Automatic Builds of Merge Requests

cbuild also builds any new merge requests. Once you mark a request as ready for review, cbuild will:

  • Take a snapshot of your feature branch
  • Queue it for building
  • Add a comment to the request saying as such
  • Add a comment as each host finishes the build saying OK or failed and showing the change in test results.

See Richard's lp-714921-4.5 for an example.

WorkingGroups/ToolChain/MakingChanges (last modified 2012-12-04 23:14:41)