This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: [PATCH] Come up with -flto=auto option.

From: Michael Matz <matz at suse dot de>
To: Jeff Law <law at redhat dot com>
Cc: Jan Hubicka <hubicka at ucw dot cz>, Martin Liška <mliska at suse dot cz>, gcc-patches at gcc dot gnu dot org, Richard Biener <richard dot guenther at gmail dot com>
Date: Tue, 23 Jul 2019 13:50:36 +0000 (UTC)
Subject: Re: [PATCH] Come up with -flto=auto option.
References: <95f20c0a-81a3-2319-326b-3c5baf71e2d1@suse.cz> <20190723092040.czs64os2qymax7sq@kam.mff.cuni.cz> <7b383b21-89ad-52ed-1fb1-e44723e8be86@redhat.com>

Hi,

On Tue, 23 Jul 2019, Jeff Law wrote:

> > great you found time to make this. It should become the default for
> > -flto IMO.
> I was going to hack it into the rpm configury bits since we have access
> to the # cores there.  But an auto-selector within GCC is even better.
> 
> BTW, isn't this all going to wreck havoc with reproducible builds since 
> partitioning can affect code generation?  That's one of our open 
> questions...

See Richi for this, but the reason for -flto=auto (or just -flto, or 
whatever the endresult will be) is _also_ reproducible builds, because 
some packages like to encode the compile flags into their binaries and 
hence would change depending on build host just because of "-flto=32" vs. 
"-flto=64" even when the code remains exactly the same.

Ciao,
Michael.

Follow-Ups:
- Re: [PATCH] Come up with -flto=auto option.
  - From: Jeff Law

References:
- [PATCH] Come up with -flto=auto option.
  - From: Martin Liška
- Re: [PATCH] Come up with -flto=auto option.
  - From: Jan Hubicka
- Re: [PATCH] Come up with -flto=auto option.
  - From: Jeff Law

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]