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