With the refactoring to (sensibly I guess?) make it somehow language-specific, it got dropped from the C FE, via which probably has more users than via the C++ FE. There are a *lot* of people relying on this (Debian and Glibc use it for ABI checking; I and others use it to help generate C bindings for my toy language without having to write a C parser for no reason). A partial workaround is to compile as C++ with an `extern "C" { }` block around the whole thing, but there is a lot of C syntax that doesn't compile in C++ ... not to mention certain headers that deliberately behave *differently* in C++ mode (e.g. strchr). Also, would it hurt to keep the old option around as an alias? That's what most options seem to do (-std=c++0x comes to mind). That just seems like gratuitous breakage.
I think it has been removed.
The raw lang dump is a terrible format, and I'd really like it to die. That it's been coerced into some kind of interchange format is just horrible. I had thought it was c++ only as that's where it started as a debugging aid during tree inlining, IIRC. Indeed the documentation (gcc 7) says: @item -fdump-translation-unit @r{(C++ only)} @itemx -fdump-translation-unit-@var{options} @r{(C++ only)} Adding Joseph.
https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01668.html
> Debian and Glibc use it for ABI checking; I and others use it to help generate > C bindings for my toy language without having to write a C parser for no reason I always have maintained that this is an abuse of the option. For most platforms using the dwarf is better and easier to maintain and independent of GCC version which might change the output of these debug options (and also language independent).
Yeah, for ABI checking you want to use dwarf, e.g. libabigail. The TU dump isn't a good source of information for ABI checking.
glibc does not use this option. ABI checking in glibc works on binaries via objdump -T. linknamespace tests do use -aux-info to list functions exported by a header, and would find it useful to be able to list exported variables as well, but while the output of -fdump-translation-unit includes variables it didn't seem at all convenient to parse for that purpose.
I saw that mailing list post, but it only explains *what*, not *why*. I never really gave consideration to DWARF, since in my little experience it is very unportable for a "standard". I suppose I could investigate it more, but ... that would require a very significant code change (since DWARF has a completely different mindset), and I don't even know if *all* the interesting trees survive that long (one of my long-term goals is to allow using C++ templates). Also, bugs that get filed against GCC's DWARF support tend to just go unfixed forever (I've filed at least 3 of them). The only real infelicity I've found in the TU dump *format* (after the high/low integers went away) is that strings aren't quoted, but that only becomes a problem if " lngt: MM\n@NNNN" occurs in the string with appropriate integers MM and NNNN. (There is also a bug I filed about wide strings not dumping). I certainly wouldn't complain if it was replaced with an XML-based format with the same general structure (don't try to make it nice, keep it raw) - parsing is the easiest part of tooling. Finally - even if GCC's internal tree layout is *theoretically* unstable - any such changes will cause more problems for people working on the compiler itself, and in practice have always been trivial to update for.
(In reply to Ben Longbons from comment #7) > I saw that mailing list post, but it only explains *what*, not *why*. > > I never really gave consideration to DWARF, since in my little experience it > is very unportable for a "standard". I suppose I could investigate it more, > but ... that would require a very significant code change (since DWARF has a > completely different mindset), and I don't even know if *all* the > interesting trees survive that long (one of my long-term goals is to allow > using C++ templates). > > Also, bugs that get filed against GCC's DWARF support tend to just go > unfixed forever (I've filed at least 3 of them). Do you have bug numbers / links for the 3 DWARF bugs? > > The only real infelicity I've found in the TU dump *format* (after the > high/low integers went away) is that strings aren't quoted, but that only > becomes a problem if " lngt: MM\n@NNNN" occurs in the string with > appropriate integers MM and NNNN. (There is also a bug I filed about wide > strings not dumping). I recognize that one; it's bug 71996 > > I certainly wouldn't complain if it was replaced with an XML-based format > with the same general structure (don't try to make it nice, keep it raw) - > parsing is the easiest part of tooling. > > Finally - even if GCC's internal tree layout is *theoretically* unstable - > any such changes will cause more problems for people working on the compiler > itself, and in practice have always been trivial to update for.
The ones I've filed are: #54533, #58150, #80466 But there are quite a few more at https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__&component=debug&list_id=190134&product=gcc
(In reply to Ben Longbons from comment #9) > The ones I've filed are: #54533, #58150, #80466 > > But there are quite a few more at > https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__&component=debug&list_id=190134&product=gcc If you type "bug" in front of them bugzilla will auto-link them: bug 54533, bug 58150, bug 80466
Nathan, what does it take to re-instantiate -fdump-lang-raw for the C frontend?
Richard, I have no idea. AFAICT all the dump_tu stuff is in the C++ FE.
this option allows on <=gcc-7 to see all global identifiers (types, builtins, etc) that the compiler predefines, currently i don't see a way to do that for c. e.g. currently there is now way to tell what _FloatN variants gcc understands, even though -fdump-translation-unit with empty tu worked for it reliably previously. (i guess i can attach gdb to cc1 and hope there is enough debug info in cc1 to print things from gcc internal data structures.. but that's not exactly userfriendly)
On Wed, 25 Sep 2019, nsz at gcc dot gnu.org wrote: > e.g. currently there is now way to tell what _FloatN > variants gcc understands, even though -fdump-translation-unit > with empty tu worked for it reliably previously. For that, I recommend checking which __FLT* predefined macros are defined (using -dM or #ifdef rather than a dump of compiler internals, or define __STDC_WANT_IEC_60559_TYPES_EXT__ and include <float.h> and check which public FLT* macros are defined there).