On 7/24/19 12:47 AM, Martin Liška wrote: > 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 Sounds good. I'll try to get it populated and at least the first level categorization done today. Matthew B. may do some additional analysis while I'm offline.
I've got scripts which can query the jenkins build failure plugin to help with that first level categorization. So, in theory, I can query for all the configury differences or query for any cases where LTO exposed a fatal warning, testsuite failures, etc. I don't want to burn a lot of time on the config.h stuff right now. At this stage we're more interested in the other failure categories. But I'm going to have to figure out something shortly after returning when I put in the Fedora 32 change request. I've got your META BZ in one of my tabs. I've referred to it several times over the last few weeks :-) jeff
