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.


On 7/23/19 7:50 AM, Michael Matz wrote:
> 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.
Makes sense.

What did you end up doing with old autoconf scripts that aren't LTO
safe?  Many of the older style tests to see if a function exists are
broken by LTO.  I've seen more issues with this than anything in the LTO
space so far.

We're capturing config.h files and comparing them with and without LTO
to at least be able to enumerate where these issues are.   Sadly this
test gets lots of false positives due to flag and timestamp encodings
into the config.h files :(

jeff


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