Linaro builds GNU toolchains for many 32-bit (arm) and 64-bit (AArch64) targets and provides them publicly as a service to our members in order to benefit the entire ARM platform eco-system. Though Linaro toolchains are provided as-is, with no support guarantee, we are committed to fixing problems that impact our members because any latent bug hit by one member is a bug that will likely effect our other members.

Here is a list of reasons to use Linaro toolchains rather than creating and maintaining your own:

Linaro toolchains have well-integrated and tested toolchain package versions.
A toolchain is a combination of several different interdependent tools (compiler, static-linker, compiler libraries, support libraries, system libraries, dynamic-linker, debugger, analysis tools) that are integrated together to target a specific platform.

Each toolchain component is managed and released by a different Free Software development group independently (with strict rules on order of feature availability). It is the responsibility of the team building the toolchain to investigate and understand the dependencies between the projects in order to select the correct versions of toolchain packages to get the desired features.

Each component might have implicit dependencies that only experienced toolchain developers know. In other words, getting the latest release of gcc X, glibc Y, bintuils Z and gdb P might not work at all! The complexity of the situation is compounded because some ARM targets to be supported are often enhanced/enabled independently of others (e.g., 32-bit arm vs 64-bit AArch64).

Assuming that mainline packages are stable can be disastrous. Experienced Linaro engineers choose package versions after careful analysis and release toolchains that are heavily integration tested.
It is very easy to misconfigure one or more packages for one or more targets in a toolchain and still get a functional toolchain.
You might build a functional toolchain that:
- is missing target variant support (e.g., bare-metal multilibs for arm mode vs thumb2 mode, missing NEON support,, not using full set of vector or float registers) but silently defaults to the slowest/lowest common denominator.
- is missing necessary targets (e.g., missing hardfp enabled toolchains, missing big-endian toolchain)
- is missing optional toolchain/compiler feature enablement (e.g., Link-time optimization, sanitizers)
- is missing hardware feature utilization (e.g., missing ARMv8.1 instruction codegen) due to incorrect package versions or missing configuration flags.
- has poorly configured system libraries that don't have runtime optimized target selection support for different variants.
- is missing candidate performance improvement patches
- is missing hardware erratum enablement due to missing configuration flags or missing patches.
Linaro continues to refine the configuration of our toolchain products with the input of all of our toolchain members, as well as with regard to the ever-changing landscape of toolchain target and feature availability.
Building toolchains becomes significantly more difficult in the event of ABI changes and may require extraordinary, unplanned changes to the toolchain.
ELF ABI (Application Binary Interface) changes will often necessitate extraordinary changes to toolchain build frameworks in order to be able to build and use toolchains on older systems while targeting newer hardware platforms. Bridging ABI changes requires costly and difficult changes to build frameworks.
Toolchain build frameworks you find on the internet just work, until they don't.
Do your engineers have the experience to solve hard problems on tight schedules?

Just because one might find a toolchain build framework script on the internet (e.g., crosstool-ng, or Linaro's ABE) and successfully build a toolchain with it doesn't mean that discovering the root cause and fixing problems with the resulting toolchain is easy. Several Linaro toolchain engineers have worked on (and written) multiple toolchain build frameworks and really understand how they work.

Linaro engineers are prepared to quickly respin toolchain releases for Linaro members to fix latent problems.
Inexperienced toolchain builders often introduce inconsistent dependencies without realizing it.
If your target hardware runs a Linux distribution with an older set of toolchain libraries than what your engineers have made available to the toolchain to link against you'll get confusing version dependencies.

Upgrading the toolchain's static-linker or compiler too aggressively might introduce a component version dependency that requires updating your other system libraries which can cascade into a complete, necessary re-versioning of every component in your toolchain.

Linaro's toolchains are configured and built by experienced toolchain release engineers who know how to avoid, identify, and fix problems with package dependencies.
Managing toolchain versions, respins, and release candidates takes engineering discipline.
You don't want to introduce toolchains into the wild that differ in functionality but have the same version strings. Supporting members and customers when there is confusion as to what products are actually being used is extremely expensive and time consuming. This disciplined approach is part of Linaro's toolchain mission.
Releasing toolchains is an ongoing effort of managing releases, not a single line item event.
It is part of Linaro TCWG's mission to continue this release process indefinitely.
Providing toolchain binaries comes with an obligation to observe GPL compliance.
Linaro is familiar and comfortable with GPL compliance obligations.
Validation of toolchain quality is expensive.
We're experts and we find and fix bugs all the time. Linaro fixes show up in our toolchains faster than your fixes will hit major Linux distribution toolchains. Linaro fixes have a higher guarantee of correctness (due to the toolchain community review) than your fixes to your own toolchain package branches that don't have the community's eyes on them.

Validation frameworks are costly to deploy and costly to maintain.
Don't fund redundant work in your own company when Linaro already provides what you need.
Linaro works to the benefit of the ARM eco-system on behalf of our members. We provide these toolchains as a service to our members. Your own engineering efforts should be lighter by adopting Linaro toolchains.
Mainline toolchain packages not only have new features, better performance, and more bug fixes, but also many latent bugs that have recently been introduced.
It is extremely important to have toolchain builders who understand development enough to pick up the right patches and select the correct versions in order to ensure stability.
Linaro toolchains provide immediate security updates.
Linaro Toolchain engineers are upstream contributions to the GNU and LLVM toolchains and are often aware of security threats (CVE) before the general public. Our toolchains are updated immediately when fixes for new security threats are discovered.
Linaro provides yearly releases of new toolchains.
Linaro's primary toolchain updates year after year following the release of the FSF GCC release. A Linux distribution toolchain updates much less frequently. This is especially true in the enterprise space with long-term-support Linux distributions. Custom/self-released toolchains might update even less frequently. Do you have it in your budget to continue to release updated toolchains?
Linaro toolchains provide improved performance over Linux distribution toolchains or toolchains built on Free Software Foundation releases.
Linaro backports performance enhancing patches into our releases. Many Linux distribution companies are extremely reluctant to take an patches other than bug fixes. Free Software Foundation packages releases do not take performance enhancement patches
Linaro toolchains provide early access to selected features.
In principle, it is ill-advised for any toolchain provider to backport new features into their toolchains. Sometime if a new feature is non-invasive (and doesn't change and API or ABI) it is a good idea. Linaro is proactive in backporting such features to our toolchains. For instance, users of Linaro toolchains will have early access to the ARMv8.1 instruction set which will impact performance.
Linaro's extensive validation matrix catches problems that are exposed in one configuration but latent in others.
For example, because we test on big-endian we find latent bugs that effect little-endian.
Since we work upstream we're able to rapidly identify important patches.
We're constantly monitoring the GNU package mailing lists as part of our development activities and are flagging candidate patches for inclusion into our toolchains.
We work closely with ARM to provide hardware erratum fixes to toolchain products as soon as possible.
Linaro is aware of ARM hardware erratum early enough to make plans to respin toolchains immediately when the fixes are posted upstream.

What are some reasons you might want to roll-your-own toolchain?

You have a tight schedule and need finer control of your toolchain releases than Linaro can provide.
You can dictate exactly how your packages are configured, and Linaro's configuration differs from what you require.
You can specify alternative toolchain 'defaults' to relieve your customers of the burden of specifying required 'special' options to support your hardware.
This can reduce support costs.
You're working on a new pre-release platform that requires invasive changes to the toolchain that cannot be shared publicly.
In this case, speak with Linaro about Linaro Premium Services.
You like what Linaro provides but you need to support configurations that are not available in the Linaro toolchain products.
You'll need a real toolchain team to maintain and support this.
You need to support more than ARM hardware with your products.