[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 --- Comment #14 from joseph at codesourcery dot com --- 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 and check which public FLT* macros are defined there).
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 nsz at gcc dot gnu.org changed: What|Removed |Added CC||nsz at gcc dot gnu.org --- Comment #13 from nsz at gcc dot gnu.org --- 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)
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 --- Comment #12 from Nathan Sidwell --- Richard, I have no idea. AFAICT all the dump_tu stuff is in the C++ FE.
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 --- Comment #11 from Richard Biener --- Nathan, what does it take to re-instantiate -fdump-lang-raw for the C frontend?
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 --- Comment #10 from Eric Gallager --- (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__=debug_id=190134=gcc If you type "bug" in front of them bugzilla will auto-link them: bug 54533, bug 58150, bug 80466
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 --- Comment #9 from Ben Longbons --- 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__=debug_id=190134=gcc
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #8 from Eric Gallager --- (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@" occurs in the string with > appropriate integers MM and . (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.
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 --- Comment #7 from Ben Longbons --- 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@" occurs in the string with appropriate integers MM and . (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.
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 --- Comment #6 from joseph at codesourcery dot com --- 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.
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- 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.
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 --- Comment #4 from Andrew Pinski --- > 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).
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 --- Comment #3 from Andrew Pinski --- https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01668.html
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542
Nathan Sidwell changed:
What|Removed |Added
CC||joseph at codesourcery dot com
--- Comment #2 from Nathan Sidwell ---
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.
[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82542 Richard Biener changed: What|Removed |Added CC||nathan at gcc dot gnu.org --- Comment #1 from Richard Biener --- I think it has been removed.
