Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 477548

Summary: sys-devel/gcc: Default to -O1 (or better) for STAGE1_CFLAGS
Product: Gentoo Linux Reporter: Matt Turner <mattst88>
Component: Current packagesAssignee: Gentoo Toolchain Maintainers <toolchain>
Severity: normal CC: sam
Priority: Normal Keywords: PullRequest
Version: unspecified   
Hardware: All   
OS: Linux   
See Also:
Package list:
Runtime testing required: ---

Description Matt Turner gentoo-dev 2013-07-21 04:38:55 UTC
sys-devel/gcc: Default to -O1 for STAGE1_CFLAGS

Saves a bunch of time and gives the same ultimate result.

gcc-4.8.1 compile went to 13:19 from 15:22 on my fast Ivy Bridge system (13% speed up). Slower systems (think alpha, mips) see much larger benefits.
Comment 1 Ryan Hill (RETIRED) gentoo-dev 2013-07-23 00:34:15 UTC
STAGE1_CFLAGS isn't set when bootstrapping, so it's whatever upstream uses.  I worked towards that on purpose since before it was a source of bugs that upstream had no interest in fixing.
Comment 2 Ryan Hill (RETIRED) gentoo-dev 2014-05-31 08:16:12 UTC
I was messing around in the build machinery again and as far as I can see we're already building stage 1 gcc with STAGE1_CFLAGS empty, ie. -O0, on native builds (we set it to an empty string because otherwise gcc sets it to BOOT_CFLAGS).  gcc itself is built with STAGE1_CFLAGS, and then libraries built by it in stage 1 (libgcc, libgomp, libstdc++-v3, etc.) use either CFLAGS or BOOT_CFLAGS, so I'm not sure how you're seeing a speed up.  Please reopen if I've missed something.  I'm looking at 4.9.0 here but I checked build logs as far back as 4.6.
Comment 3 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-09-28 11:26:29 UTC
Times have changed. made me revisit this.

It also turns out the GCC developers often use STAGE1_CFLAGS to speed things up:

Previous times for gcc 13:
2023-07-30T19:51:46 >>> sys-devel/gcc-13.2.1_p20230729: 1:21:36
2023-08-01T16:16:22 >>> sys-devel/gcc-13.2.1_p20230729: 1:45:12
2023-08-06T00:12:55 >>> sys-devel/gcc-13.2.1_p20230805: 1:22:01
2023-08-13T02:13:36 >>> sys-devel/gcc-13.2.1_p20230812: 1:37:06
2023-08-20T07:07:07 >>> sys-devel/gcc-13.2.1_p20230819: 1:43:02
2023-08-27T00:27:00 >>> sys-devel/gcc-13.2.1_p20230826: 1:42:41
2023-09-01T04:49:42 >>> sys-devel/gcc-13.2.1_p20230826: 1:31:57
2023-09-02T00:54:34 >>> sys-devel/gcc-13.2.1_p20230826: 1:36:01
2023-09-03T05:34:29 >>> sys-devel/gcc-13.2.1_p20230902: 1:37:19
2023-09-10T08:00:56 >>> sys-devel/gcc-13.2.1_p20230909: 1:37:42
2023-09-17T01:24:05 >>> sys-devel/gcc-13.2.1_p20230916: 1:34:30
2023-09-24T02:34:47 >>> sys-devel/gcc-13.2.1_p20230923: 1:40:26
2023-09-28T07:30:17 >>> sys-devel/gcc-13.2.1_p20230923: 1:34:10
2023-09-28T11:12:54 >>> sys-devel/gcc-13.2.1_p20230923: 1:11:17 <-- with the change

That seems like a consistent improvement of, in the most consrvative intepretation, 10 minutes, and possibly as much as 25-30 minutes.
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-09-28 11:47:49 UTC
(In reply to Sam James from comment #3)
(all times w/ USE="lto pgo")
Comment 5 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-09-28 13:00:55 UTC
For gcc 12 w/ USE="-lto -pgo":
2023-07-08T04:44:25 >>> sys-devel/gcc-12.3.1_p20230707: 47′06″
2023-07-15T10:24:27 >>> sys-devel/gcc-12.3.1_p20230714: 52′59″
2023-07-22T02:03:14 >>> sys-devel/gcc-12.3.1_p20230721: 44′05″
2023-07-30T11:19:23 >>> sys-devel/gcc-12.3.1_p20230728: 38′57″
2023-08-01T15:53:00 >>> sys-devel/gcc-12.3.1_p20230728: 53′05″
2023-08-05T02:21:16 >>> sys-devel/gcc-12.3.1_p20230804: 34′04″
2023-08-12T05:08:44 >>> sys-devel/gcc-12.3.1_p20230811: 45′00″
2023-08-19T05:51:16 >>> sys-devel/gcc-12.3.1_p20230818: 39′07″
2023-08-26T00:25:48 >>> sys-devel/gcc-12.3.1_p20230825: 42′37″
2023-09-02T00:25:47 >>> sys-devel/gcc-12.3.1_p20230825: 50′56″
2023-09-02T13:01:14 >>> sys-devel/gcc-12.3.1_p20230901: 40′42″
2023-09-09T03:05:45 >>> sys-devel/gcc-12.3.1_p20230908: 43′13″
2023-09-16T05:14:22 >>> sys-devel/gcc-12.3.1_p20230915: 43′11″
2023-09-23T00:46:41 >>> sys-devel/gcc-12.3.1_p20230922: 47′33″
2023-09-28T13:25:57 >>> sys-devel/gcc-12.3.1_p20230922: 34′00″

so a clear improvement again.
Comment 6 Larry the Git Cow gentoo-dev 2023-09-30 09:38:54 UTC
The bug has been closed via the following commit(s):

commit bb2d045c02a6ca647ef3280f4987cbc0d14e5a7e
Author:     Sam James <>
AuthorDate: 2023-09-28 23:27:06 +0000
Commit:     Sam James <>
CommitDate: 2023-09-30 09:38:40 +0000

    toolchain.eclass: rework bootstrapping logic
    * Build stage1 compiler with user's CFLAGS. This consistently ends up
      saving at least 15 minutes for me on a fast amd64 machine and should save
      more on slower machines and architectures.
      There's only any risk here if the host compiler is ancient/very buggy and
      even then, you get a failed bootstrap later on. The GCC developers, per the
      linked bug, end up using STAGE1_CFLAGS="-O2" anyway to speed up the process
      so it's not like this is untested at all.
      mattst88 actually brought this up.. 10 years ago (bug #477548). Let's try
      make that right now.
    * Respect LDFLAGS for target libraries for native builds. Not touching this
      for cross builds, at least for now, as it's a bit more delicate.
      (Unfortunately, we have to put a hack in here for now until we can fix
      multilib.eclass - see bug #914881).
    Apologies-to: Matt Turner <>
    Signed-off-by: Sam James <>

 eclass/toolchain.eclass | 52 +++++++++++++++++++++++++++++++++----------------
 1 file changed, 35 insertions(+), 17 deletions(-)
Comment 7 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2023-09-30 09:45:05 UTC
(In reply to Ryan Hill (RETIRED) from comment #2)
> I was messing around in the build machinery again and as far as I can see
> we're already building stage 1 gcc with STAGE1_CFLAGS empty, ie. -O0, on
> native builds (we set it to an empty string because otherwise gcc sets it to

Just to be clear: this was precisely the problem (building with no optimisation).

I didn't quite get what Ryan meant here, until Matt and I discussed it on IRC, and concluded the consensus must have been "well, it's slower to build with the optimisations" and hence it'd be going -O2 -> -O1 or something rather than -O0 -> -O1.