Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#71476 - [gcc] speed up the build (a lot!)

Attached to Project: Arch Linux
Opened by Toolybird (Toolybird) - Saturday, 10 July 2021, 01:57 GMT
Last edited by Allan McRae (Allan) - Saturday, 10 July 2021, 07:24 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 4
Private No


TL;DR -> Arch should build GCC with `make STAGE1_CFLAGS="-O2"' for a 20% speed up in compile time.

Arch uses the standard GCC build procedure which performs a 3-stage bootstrap. The stage 1 compiler is built with the host GCC and is eventually discarded. An interesting thing about the stage 1 compiler is that it's built with no optimization at all. Consequently it's slow AF.

The reason why the GCC build is designed this way is so that GCC can be bootstrapped on a wide variety of hosts i.e. Linux hosts with old GCC versions or even exotic *nixen with proprietary compilers that nobody uses anymore.

A trick[1] that some GCC devs use[2] to speed up the development cycle is to build stage 1 with optimization. This should only be used with modern'ish host GCC's. It's as simple as:

make STAGE1_CFLAGS="-O2"

This results in a significant time saving. For example on my Ryzen 2700x with -j16, the "make" portion of the build goes from this:

real 40m3.753s
user 383m1.195s
sys 23m12.625s

to this:

real 32m2.818s
user 304m48.800s
sys 24m26.025s

That's approx 20% speed up!

Because Arch is a rolling distro, the worst case for the host bootstrap compiler is:

current GCC version - 1
current GCC version

That's what makes this IMHO a no brainer! What do you think?

PS - The end result binaries are identical (apart from gcc-go, but that's a separate GCC 11 reproducibility issue already under investigation).

This task depends upon