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. Martin > > 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 >
