On Fri, 2019-12-20 at 11:52 +0100, Miro Hrončok wrote: > On 19. 12. 19 22:41, Ben Cotton wrote: > > https://fedoraproject.org/wiki/LTOByDefault > > > > == Contingency Plan == > > * Contingency mechanism: Revert the LTO flags injection > > * Contingency deadline: Beta freeze, but shooting for prior to mass > > rebuilds starting > > * Blocks release? No > > * Blocks product? No > > > > Most critically, if we don't address the GDB testsuite issue noted > > above, our fallback position would be to simply disable the LTO > > injection globally and re-evaluate for Fedora 33, similarly if we were > > to find some show-stopping LTO issue. > > Should the contingency plan include a second mass rebuild in case our packages > successfully built with lto during the mass rebuild, but are broken at runtime? > > Or do we safely assume that it's good as long as it builds fine? It would really depend on what we find and it's the kind of decision we deal with semi-regularly with the yearly compiler update in Fedora -- what to do if we find something horrifically wrong, whether it be an unexpected ABI change or a particularly nasty codegen issue. When we encounter these situations we often end up instrumenting the compiler to get a sense of how pervasive the problem is or building a scanner to look for problematic code sequences across the builds done with the problematic compiler/options. To-date I don't think we've ever had to do something like back out a major compiler update or request a mass rebuild in Fedora as a result of a compiler issue. We've had some "phew" moments for issues we thought were going to have wide impact, but for various reasons didn't. So while I wish I could give you a concrete answer, it's really something we (Jakub, Marek, Jason, Jon, myself and others) evaluate on a case by case basis looking at size/scope and determine a path forward, knowing that an unexpected mass rebuild would be catastrophic. What gives me a relatively high degree of confidence in the introduction of LTO is that openSUSE made this change for their distro in the spring of this year confirming the base LTO technology on a wide scale, combined with the testing we're already doing for Fedora with gcc-10. By *far* the biggest issue with LTO is the configure test snippets that are so horribly written that they can be easily compromised by aggressive optimization enabled by LTO and the widespread nature of that horrific code. Hence the desire to fix the most common and egregious issues by in-place editing of the already-generated configure files within %configure. And just to be clear, these code snippets would never actually run and nobody would ever write code this way expecting it to be executed -- they're primarily compile/link tests to look for features. Concerns over mis-configuring packages due to these issues is what led to the introduction of the capability to capture the generated config.h files and compare them against builds with standard tools in our tester. If we note any differences in the generated config.h files, the build is considered a failure and needs to be examined and the issue fixed. jeff _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
