http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> 2013-01-09 09:22:21 UTC --- (In reply to comment #11) > > All that to avoid one #include "output.h" in one file? > > Is that one little thing really the only change you see? I see a > different picture. > > The change is a major step in the direction of making a clear cut > between the middle/back end and the front ends. A front end should not > output assembly, period, if we want the front ends to become separate > libraries, in the long run, that can be used by external tools (static > checkers, IDEs, etc.) like clang. For the long term, this is IMHO the > only viable solution for keeping the GCC front ends relevant. > > The change also allows the compiler to open the assembler file in > write-only mode and to open it only after the front end is done. My > plan is to postponed it even further: for GCC 4.9 I'd like to work on > streaming slim LTO objects directly to a .o file, without going > through an assembler file at all (this is relatively simple for ELF > targets). > > Finally, the change also simplifies the PCH mechanism further. If > we're ever going to replace PCH-as-a-memory-dump with something > streamed, we'll have to make an effort at only streaming IR objects, > not assembler output. > > Had I known this change would break stabs like this, I'd obviously > have tried to solve that problem first. But to back out the change now > would be a mistake. Nobody is going to fix those *out.c back ends, as > you very well know. That's exactly my thinking of the whole picture. Timing seems to be bad now - so as compromise I'd accept reverting the patch for 4.8 and immediately re-installing it when stage1 for 4.9 re-opens. If dwarf2out.c is really set up nicely enough (just dump its internal dwarf tree to asm_out_file at some point) then doing dwarf -> Y translation at that point should be possible. Of course I don't see anybody doing that either - nobody is really interested in debug formats besides dwarf apart from keeping the legacy going. IMHO we can direct them to use oder versions of GCC. Thus, let's deprecate anything but dwarf in 4.8 ;)
