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

["Martin Liška" <mliska@suse.cz>]

On 7/24/19 12:32 AM, Jeff Law wrote:
> On 7/23/19 8:23 AM, Martin Liška wrote:
>> On 7/23/19 3:57 PM, Jeff Law wrote:
>>> 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.
>>
>> Well, I've seen some of these failures, but only a few.
> Many appear to be silent, possibly not really affecting anything (like
> all the packages that test for doprnt, but really don't care about it in
> the end).    But there were enough real failures that I put in auditing
> to detect any cases where we get different config.h files with LTO vs
> non-LTO and that is tripping often enough to have my concerns about how
> much work it's going to be to get everything fixed.

I see.

> 
> 
> But still, overall we're moving forward.  Next step is to get everything
> classified into buckets and start iterating.  Presumably you'd be open
> to a google doc of some kind where we can coordinate any such efforts?

Sure, I'm open. In the meantime, I've got a META issue that I use for tracking
of LTO-related issues in openSUSE:
https://bugzilla.opensuse.org/show_bug.cgi?id=1133084

Martin

> 
> jeff
> 
> ps.  I'm on PTO July 25 to Aug 5, so not much is going to happen in the
> next couple weeks :-)
>