On Wed, 30 Sep 2020 01:31:29 +0200, Jeff Law wrote: > -fdebug-types-section a supported option in the sense that it's in the > compiler and we'll fix bugs in it when we can. But the GCC community > doesn't really test that option and it's known to be broken with LTO. I believe you base this information on Jakub Jelinek's internal company mail: Message-ID: <20200710092926.GJ2363@tucnak> IIUC that mail contains incorrect information. My apologies if my deduction is incorrect, I am also writing "IIUC" here. I am basing my information on explanation by GCC developer Richard Biener: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88878#c8 It is explained there "in_lto_p" means GCC is in second/later phase of LTO. Not that LTO is enabled at all (as Jakub Jelinek said in the internal mail). Also GCC does not produce ICEs (=compiler crash, (*)) Jakub Jelinek was claiming will happen during the 20000+ packages rebuild with LTO and -fdebug-types-section I have done. So I really see no indication why GCC would not normally support -fdebug-types-section even with LTO. Also it is so simple optimization of DWARF there is no reason why there should be any longterm issues with it. Jan (*) There were 7 packages reproducing GCC crashes due to the following two GCC Bugs specific to -fdebug-types-section. That is unrelated to the topic of the "in_lto_p" condition discussed above. ICE: fortran+gnat: build_abbrev_table, at dwarf2out.c: -g -fdebug-types-section https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96471 ICE: c++: dwarf2out_abstract_function, at dwarf2out.c: -g -fdebug-types-section https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96472 _______________________________________________ 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