[Bug bootstrap/54696] Makefile doesn't propagate CPPFLAGS to host libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54696 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #5 from Tom Tromey --- This came up for gdb as well https://sourceware.org/pipermail/gdb-patches/2024-June/209725.html
[Bug fortran/49565] character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49565 --- Comment #13 from Tom Tromey --- (In reply to anlauf from comment #12) > After reading this ancient thread, I don't see anything left to do. Closing. GCC still emits <1>: Abbrev Number: 1 (DW_TAG_base_type) DW_AT_byte_size : 4 DW_AT_encoding: 7(unsigned) DW_AT_name: (indirect string, offset: 0x43): character(kind=4) i.e., DW_ATE_unsigned. That still seems incorrect to me, so I think this should be reopened.
[Bug libcc1/113977] debug info for alignment of structure is unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977 --- Comment #13 from Tom Tromey --- This is fixed on trunk now. I think that means it'll be in GCC 14... ? Which maybe I shouldn't have done according to the current status. Anyway, I'm not sure any more how gcc manages bugs, so I don't know if I should close this or what. gdb fix still not in, will do that soon.
[Bug rtl-optimization/38534] gcc 4.2.1 and above: No need to save called-saved registers in 'noreturn' function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534 --- Comment #39 from Tom Tromey --- (In reply to Lukas Grätz from comment #36) > > #2 0x004011d2 in baz (a=a@entry=42, b=b@entry=43, c=c@entry=44, > > d=, > > e=, f= > reading variable: value has been optimized out>, g=48, h=49) at /tmp/1.c:38 > > > I can confirm that. What bothers me, is the wording "d= out>" and not just "d=". Could you file a gdb bug about this? Preferably with some kind of test case?
[Bug libcc1/113977] debug info for alignment of structure is unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977 Tom Tromey changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tromey at gcc dot gnu.org --- Comment #11 from Tom Tromey --- I have a patch.
[Bug libcc1/113977] debug info for alignment of structure is unspecified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113977 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #9 from Tom Tromey --- I think this should be reopened -- some of the fix has to happen in libcc1. When this code was written, there was no way to find the alignment in DWARF. That's since been fixed but the protocol wasn't updated. There are some comments about this, see libcc1/libcc1plugin.cc: // FIXME there's no way to get this from DWARF, // or even, it seems, a particularly good way to deduce it. SET_TYPE_ALIGN (record_or_union_type, TYPE_PRECISION (pointer_sized_int_node));
[Bug debug/8188] DW_AT_containing_type incorrectly emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8188 --- Comment #6 from Tom Tromey --- I wanted to mention -- I don't particularly care if this attribute goes away or not (assuming it indeed doesn't negatively affect gdb), but I do dispute the idea that DWARF proscribes which attributes may or may not appear. DWARF itself claims to be lenient in the text. Extensions like this are, and should be, commonplace; and readers ought to ignore attributes they do not understand.
[Bug debug/8188] DW_AT_containing_type incorrectly emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8188 --- Comment #5 from Tom Tromey --- The uses in gdb seem to all be for the old v2 C++ ABI. Removing them might break that code, but OTOH that code is untested, probably already broken, and anyway long since obsolete. Note that Rust+LLVM use this attribute as an extension, to associate a vtable with a concrete type. This is what lets trait objects work in gdb. There was a thread on the GCC list (IIRC) about doing something similar for C++; however, I can't find the thread now.
[Bug debug/99178] Emit .debug_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178 --- Comment #7 from Tom Tromey --- (In reply to David Blaikie from comment #6) > Ideally that'd be detected by looking at the abbreviation table, rather than > the augmentation string - if parent info is necessary for a usage of the > table, that'd be a generic way to check for it & ensure the unusable indexes > are ignored while not ignoring usable ones. Good idea. > Ah, but yeah, if you need extensions, then positive augmentation string > checking seems likely necessary. It's possible we could accept indexes without the extensions and sort of limp along or have bugs. Not sure offhand. > (though this starts to feel like websites checking browser versions, > unfortunately :/ ) https://github.com/rust-lang/rust/issues/41252#issuecomment-293676579 > Any sense of how bad the performance is if names without template parameters > (strawman: this could be communicated via another flag on the entry in the > index) did require DWARF parsing to check template parameters? It can be bad -- gdb actually has a related bug right now: https://sourceware.org/bugzilla/show_bug.cgi?id=30520 (There's a few possible dups of this.) Maybe it would be possible to do some kind of 2-phase expansion. But we already have 2 DWARF scanners and this would be adding a 3rd... > Hmm, I missed a step here - perhaps you can help me understand. Maybe, > ultimately, I agree with you here - I've pushed back on the lldb folks > relying on character identical name lookup in the index due to the problems > you've described (there's no real canonical demangling) - but where does > DWARF say that writers should "use the system demangling style"? https://wiki.dwarfstd.org/Best_Practices.md See also bug#94845. > Oh, that makes loads of sense - yeah, beats me how lldb deals with tab > completion using the hash table... maybe it builds some other side table or > something. That's something I've wondered about for a while and it's good to > know how GDB deals with this, and why its index looks different. FWIW you can't really go by what gdb does today: its .debug_names it just super wrong, and .gdb_index is a hash table but explicitly relies on the name canonicalization that gdb does. Which itself is unsafe (like what if that changes between versions) but we didn't really think through all the problems back then. > Does that mean you want the entries in the table to be sorted? Do you emit > them that way and then, based on augmentation string, rely on them being > sorted? Or do a quick scan at startup and build a sorted list in memory > regardless of the order in .debug_names? (.debug_names entry list isn't > suited to random access, is it? The records aren't all the same size so I > don't think you could binary search through them) The new reader just reads the entries and creates the same internal data structures that the new DWARF scanner creates. It handles sorting, canonicalization, etc, during the scan. This work is done in a worker thread to hide it from the user (although I think it's reasonably quick anyway). > > The only other thing I can think of offhand is that the reliance on > > .debug_str means that gdb may have to augment the string table when > > DW_FORM_string is in use. This is also caused by the "(anonymous > > namespace)" > > special case. > > And Split DWARF, I guess? The strings wouldn't otherwise be in the > executables .debug_str if not for the index - they'd only appear in the > dwo/dwp .debug_str.dwo sections. Yeah, I haven't really looked at this too much.
[Bug debug/99178] Emit .debug_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178 --- Comment #5 from Tom Tromey --- (In reply to David Blaikie from comment #4) I don't remember filing this bug. At the time maybe I thought it would be worthwhile to have "end to end" .debug_names generation, that is, to try to have the index and also not slow down compilation or link times too much. Not sure how I feel about it now. > It'd be great to get GCC/GDB folks take on the name tables - get some > practical experience with their contents, file any bugs about missing > elements, etc. It's possible they're leaning too heavily towards lldb's > style of name lookup since they derived from an existing apple > implementation there & it'd be good to generalize them where needed. gdb has long done the wrong thing with .debug_names. https://sourceware.org/bugzilla/show_bug.cgi?id=24820 I don't really know how/why that happened. However, I wrote patches to fix it: https://sourceware.org/pipermail/gdb-patches/2023-December/204949.html This version of gdb will look at the augmentation string and only allow certain indexes to be used. This is done to avoid known bugs -- mainly coming from the "old" (current) gdb, but also clang has some issues (from memory, it doesn't include parent info). Also, gdb relies on its extensions (see below). When writing the new scanner, I found a few bugs in DWARF related to which names appear in the index. I don't recall offhand what these are, and I didn't file them due to the late unpleasantness (sorry). They could probably be dug up by reading the scanner and comparing to the spec. gdb will also emit some extensions. You can see these in the docs patch: https://sourceware.org/pipermail/gdb-patches/2023-December/204947.html Generally the goal of these is to avoid having to do any DIE reading in order to reject a lookup. Note that this means gdb relies on template parameters being in the name -- something we discussed in gdb bugzilla a bit. With these patches, gdb will not generate or use the hash table. This is explained here: https://sourceware.org/pipermail/gdb-patches/2023-December/204963.html The only other thing I can think of offhand is that the reliance on .debug_str means that gdb may have to augment the string table when DW_FORM_string is in use. This is also caused by the "(anonymous namespace)" special case.
[Bug other/9346] make uninstall does not remove all files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=9346 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #8 from Tom Tromey --- (In reply to Andrew Pinski from comment #6) > uninstall is hard to support really because it means backing up everything > install will overwrite. This is hard to do really. Also it is easy to > install in a clean directory and just remove that directory if you want > uninstall GCC. GNU style "make uninstall" just deletes any files installed by "make install".
[Bug libffi/67801] error in libffi documentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67801 --- Comment #4 from Tom Tromey --- This was fixed by commit 92456a4e5658e138e2cea79e390e3306b07685b0 Author: H.J. Lu Date: Tue Aug 31 07:14:47 2021 -0700 libffi: Sync with libffi 3.4.2 Merged commit: f9ea41683444ebe11cfa45b05223899764df28fb I'm not sure when it's ok to close a GCC bug, so I'm leaving this open.
[Bug debug/44126] wrong location description for DW_AT_vtable_elem_location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44126 --- Comment #7 from Tom Tromey --- I happened to be looking in this area and I see that gcc still generates the old, incorrect form.
[Bug fortran/49475] [OOP][debugging] Add DWARF info for Fortran's OOP features (extension, member functions)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49475 --- Comment #4 from Tom Tromey --- Note that ifort implemented this and gdb supports that now. See https://sourceware.org/bugzilla/show_bug.cgi?id=22497 for some info.
[Bug c++/108811] New: add enum annotation for switch statements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108811 Bug ID: 108811 Summary: add enum annotation for switch statements Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- In gdb we don't generally want -Wswitch-enum, because there are many switches where it's not appropriate. However, for a subset of switch statements, it is nice to have -- it means we can make them "future proof" against things like adding a new type code. Right now we can do this by pushing and popping diagnostics. However, this relies on remembering to surround the switch with some macros. It would be nice, instead, to have an attribute we could apply to the switch statement itself. Then we'd only have to mark a single spot, like: [[gnu::switch_enum]] switch (...)
[Bug c++/94845] DWARF function name doesn't match demangled name in base type template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94845 --- Comment #10 from Tom Tromey --- See also bug #49130 and bug #49537, which we filed when gdb hit these same problems.
[Bug c++/105798] New: Add new -Wshadow for data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105798
Bug ID: 105798
Summary: Add new -Wshadow for data member
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
While refactoring gdb -- changing a function to a method --
I accidentally introduced a self-assign, because the function
used local variables that had the same name as the class members.
gdb uses -Wshadow=local... I don't recall why but it seems like
it would be nice to have a level between 'local' and 'global'
so we could prevent locals from shadowing class members but
still not care about globals.
Test case:
struct x {
int f;
int y(int x) {
int f = x;
return f;
}
};
This warns with -Wshadow but not -Wshadow=local.
[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446 --- Comment #8 from Tom Tromey --- This behavior can also be affected by the choice of linker, see bug #91239.
[Bug debug/87432] LTO produced debug info makes gdb slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87432 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #2 from Tom Tromey --- (In reply to Richard Biener from comment #0) > For example starting gdb on LTO bootstrapped cc1 takes s and ~1.8GB memory > for me. Setting a breakpoint on do_rpo_vn takes another 3s. That feels a > lot slower than doing this on a non-LTO bootstrapped cc1. > > This bug is to track what _GCC_ can do better here. Note that in gdb, those are two different code paths. We recently rewrote the initial scan to be much faster (10x improvement isn't uncommon). This affects the startup time. However, setting a breakpoint currently requires a full CU expansion. That's still probably slow. For gdb performance the best thing for this case is if each CU is reasonably small.
[Bug debug/91239] gcc generates invalid .debug_macro sections (according to lld folks)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239 --- Comment #3 from Tom Tromey --- Created attachment 52836 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52836=edit test program I thought I'd upload the sources. You can just untar. Compile with "gcc -g3 -O0 r.cc z.cc -o z" If you link with mold or lld, you'll see 0x0 imports in .debug_macros. If you link with gold or the bfd ld, that won't happen. While I think this behavior seems unwanted on the part of mold/lld, on the other hand perhaps it really is allowed by ELF, I don't know.
[Bug debug/91239] gcc generates invalid .debug_macro sections (according to lld folks)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239 Tom Tromey changed: What|Removed |Added Status|WAITING |NEW CC||tromey at gcc dot gnu.org --- Comment #2 from Tom Tromey --- I separately discovered this problem when debugging an apparent gdb slowdown, which I tracked down to a pathological .debug_macro section -- but only when I switched to using 'mold' to link. > So how does a testcase look like? [...] > Can you possibly share two source files and instructions to reproduce the > conflicting comdats? I filed a trivial example (three very short files) with mold: https://github.com/rui314/mold/issues/438 I'm taking the liberty of moving this out of "WAITING".
[Bug libcc1/67590] libcc1 cannot find objdump when cross build native
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67590 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #2 from Tom Tromey --- This use seems to come from config/gcc-plugin.m4. So, I think the patch ought to be applied there, and I suppose the code from gcc/configure.in removed.
[Bug bootstrap/65763] tm.h: No such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65763 Tom Tromey changed: What|Removed |Added CC||townsend at astro dot wisc.edu --- Comment #7 from Tom Tromey --- *** Bug 64320 has been marked as a duplicate of this bug. ***
[Bug libcc1/64320] Missing config.h during findcomp.cc compilation when srcdir=objdir
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64320 Tom Tromey changed: What|Removed |Added Status|NEW |RESOLVED CC||tromey at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Tom Tromey --- The patch here, that was reported as fixing the problem, was fixed in bug #65763. *** This bug has been marked as a duplicate of bug 65763 ***
[Bug libcc1/63792] libcc1 doesn't built i386 multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63792 Tom Tromey changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Tom Tromey --- I'm going to close this, as I don't think there's a bug here. If you disagree, please reopen, and I guess then it would be good to know why. Thanks.
[Bug libcc1/65817] libcc1: ICE: SEGV: c_incomplete_type_error()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
Tom Tromey changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
--- Comment #4 from Tom Tromey ---
Tried it again today and it seems fine:
(gdb) compile code sv.p = printf("%p %p\n",,sv.p);
gdb command line:1:12: warning: incompatible implicit declaration of built-in
function ‘printf’ [-Wbuiltin-declaration-mismatch]
gdb command line:1:1: note: include ‘’ or provide a declaration of
‘printf’
0x402010 0x402010
Going to close the bug this time.
[Bug libcc1/67128] Makefile.in, libcc1 and --enable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128 --- Comment #8 from Tom Tromey --- *** Bug 96240 has been marked as a duplicate of this bug. ***
[Bug bootstrap/96240] Error in building gcc-11 with --disable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96240 Tom Tromey changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Tom Tromey --- > No it is about libcc1 when --disable-shared is passed. Just it is linking > against libstdc++ where the error is from. It might be a top level option > that needs to similar to libjit. Alright, in that case it really is a dup. *** This bug has been marked as a duplicate of bug 67128 ***
[Bug libcc1/67128] Makefile.in, libcc1 and --enable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128 Tom Tromey changed: What|Removed |Added CC||skunk at iskunk dot org --- Comment #7 from Tom Tromey --- *** Bug 66955 has been marked as a duplicate of this bug. ***
[Bug libcc1/66955] Bootstrap error: libcc1 compiled as shared library despite --disable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66955 Tom Tromey changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE CC||tromey at gcc dot gnu.org --- Comment #6 from Tom Tromey --- This is a dup. I think libcc1 has to be built shared. So if you want --disable-shared, also use --disable-libcc1. Maybe libcc1 should disable itself -- something to discuss in the other bug. *** This bug has been marked as a duplicate of bug 67128 ***
[Bug libstdc++/96240] Error in building gcc-11 with --disable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96240 Tom Tromey changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|UNCONFIRMED Component|libcc1 |libstdc++ --- Comment #2 from Tom Tromey --- Sigh. Un-duping this, I assumed the component was correct. This isn't about libcc1 at all, it's about libstdc++. Sorry about that.
[Bug libcc1/67128] Makefile.in, libcc1 and --enable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128 Tom Tromey changed: What|Removed |Added CC||570070308 at qq dot com --- Comment #6 from Tom Tromey --- *** Bug 96240 has been marked as a duplicate of this bug. ***
[Bug libcc1/96240] Error in building gcc-11 with --disable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96240 Tom Tromey changed: What|Removed |Added Resolution|--- |DUPLICATE CC||tromey at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from Tom Tromey --- I think this is a dup. libcc1 has to be built shared. Maybe it should automatically disable itself, I don't know; but otherwise you can --disable-libcc1 if you really want a no-shared build. *** This bug has been marked as a duplicate of bug 67128 ***
[Bug libcc1/67128] Makefile.in, libcc1 and --enable-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67128 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #5 from Tom Tromey --- I don't think it really makes sense to build libcc1 as a static library. It is a gcc plugin and so has to be available for dlopen. That's the only way it can be used. So I guess if you really want --disable-shared then you ought to do as suggested in comment #3 and --disable-libcc1 as well.
[Bug c/94669] libcc1: 4 * minor performance problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669 --- Comment #8 from Tom Tromey --- (In reply to David Binderman from comment #7) > Could this bug be marked as fixed, then ? Yes, but I don't really know the GCC rules about closing reports any more, so someone else probably ought to handle it.
[Bug c++/79531] bad location when trying to define undeclared method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79531 --- Comment #3 from Tom Tromey --- (In reply to Andrew Pinski from comment #2) > Which seems ok, unless I am missing something. Looks good to me too, IMO you could close this bug.
[Bug debug/100446] GDB has problems reading GCC's debugging info level -g3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100446 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #6 from Tom Tromey --- (In reply to Richard Biener from comment #1) > I commented on the gdb issue, since -flto/-fno-lto have comparable > .debug_macro the issue must lie with gdb. Sorry for just shifting the blame > ;) If you look at "readelf --debug-dump=macro" on that file, the results are very strange. For example, one of the CUs in the macro section does this: DW_MACRO_import - offset : 0x0 DW_MACRO_end_file ... a total of 108 times. In one spot it does this 3 times in a sequence. That doesn't seem right, or even useful, to me.
[Bug preprocessor/100435] oddity in hash table use in libcpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100435 --- Comment #2 from Tom Tromey --- (In reply to Richard Biener from comment #1) > I think it's just an omission and indeed a bug. I can write a patch easily enough, but I don't have a good way to test it.
[Bug preprocessor/100435] New: oddity in hash table use in libcpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100435 Bug ID: 100435 Summary: oddity in hash table use in libcpp Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- I noticed that the libcpp hash tables in libcpp/files.c use htab_hash_string, but compare filenames with filename_cmp. This by itself is not a bug, in the sense that it can't cause hash table corruption. However, it seems strange, because it means that two filenames that compare equal can hash differently, and so the hash tables will not notice that they are "the same". I think any problem here would most likely be a performance issue, and only be available when either HAVE_CASE_INSENSITIVE_FILE_SYSTEM or HAVE_DOS_BASED_FILE_SYSTEM is defined. If this is in fact a bug, the fix would be to use filename_hash rather than htab_hash_string in this file. There are multiple uses to fix. If this is intentional, feel free to just close this bug. I found this by reading the code while looking into something else, and I thought it was odd enough to report; but I haven't encountered any actual problem.
[Bug c++/94845] DWARF function name doesn't match demangled name in base type template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94845 --- Comment #8 from Tom Tromey --- (In reply to rob...@ocallahan.org from comment #7) > So gdb reads DW_AT_name "func", parses it, reserializes it to > "func", and uses that? Yeah. (Actually it's even worse than that, because at least one compiler doesn't emit the template parameters in the name, so in that case gdb will read the children of the DIE to try to construct this form.) I think the reasoning behind the canonicalization is two-fold. First, I think we tried to get g++ changed, back in the day, without success. Second, gdb has to canonicalize user input anyway, so that things like "print func(3)" or "break func" work. And once you have a canonicalizer it is simpler to just use it to work around the problem.
[Bug c++/94845] DWARF function name doesn't match demangled name in base type template parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94845 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #6 from Tom Tromey --- gdb does this canonicalization precisely because the form in the DWARF cannot be relied upon. It would be great to remove this, because it is expensive. One idea for a migration route would be for g++ to promise to emit the same form that the demangler emits; then add an attribute to the comp-unit DIE saying that the names have been canonicalized. (Or, I suppose gdb could use producer sniffing; but I'd rather avoid that as much as possible.)
[Bug debug/99178] New: Emit .debug_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178 Bug ID: 99178 Summary: Emit .debug_names Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- DWARF 5 includes a new index section, .debug_names. GCC should emit this with -gdwarf-5
[Bug plugins/65817] libcc1: ICE: SEGV: c_incomplete_type_error()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #3 from Tom Tromey --- I think this was fixed by commit 8db29d88f3e8d5fc43b25d9e0049c25f6bfb74d1 Author: Alexandre Oliva Date: Tue Jan 31 01:02:03 2017 + Introduce C++ support in libcc1 in particular the code now does tree node = make_node (code); tree type_decl = build_decl (input_location, TYPE_DECL, NULL_TREE, node); TYPE_NAME (node) = type_decl;
[Bug other/63792] libcc1 doesn't built i386 multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63792 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #1 from Tom Tromey --- libcc1 is a host library, not a target library. So, I suspect nothing needs to be done here.
[Bug c/94669] libcc1: 4 * minor performance problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669 Tom Tromey changed: What|Removed |Added CC||tromey at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |tromey at gcc dot gnu.org --- Comment #5 from Tom Tromey --- I have a patch for these.
[Bug c/47781] warnings from custom printf format specifiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47781 --- Comment #24 from Tom Tromey --- (In reply to David Crocker from comment #23) > I need this feature too. Instead of waiting several more years for an > all-singing all-dancing solution, PLEASE can we have a simple solution that > allows me to use a custom format specifier and skips a single argument for > that specifier. I believe this would cover the vast majority of uses custom > format specifiers. My particular use case is that my application generates a > lot of JSON strings, so in my printf replacement I want to implement a > specifier similar to %s that performs JSON escaping on characters in the > string. As a workaround, see the kernel doc linked earlier in this bug. gdb uses this hack as well -- e.g., it uses "%ps" in its formatter to mean a styled string, passed as a pointer to get past gcc's checking.
