[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.
[Bug fortran/95509] [11 regression] gfortran.dg/spellcheck-operator.f90 fails after r11-875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509 Tom Tromey changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Tom Tromey --- Fixed.
[Bug fortran/95509] [11 regression] gfortran.dg/spellcheck-operator.f90 fails after r11-875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509 --- Comment #3 from Tom Tromey --- https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547388.html
[Bug fortran/95509] [11 regression] gfortran.dg/spellcheck-operator.f90 fails after r11-875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509 Tom Tromey changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tromey at gcc dot gnu.org --- Comment #2 from Tom Tromey --- Sorry about that.
[Bug c/95379] Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379 --- Comment #7 from Tom Tromey --- (In reply to Asher Gordon from comment #6) > (In reply to Tom Tromey from comment #5) > > Since this warning is intended to work like sparse, introducing > > a divergence here would seem to make the feature less useful, > > in fact subverting the point of having it. > > How does diverging from Sparse make the feature less useful? If this is the > case, perhaps Sparse's behavior should be changed as well. The feature was added specifically to mimic what sparse does. If sparse changes, I think changing gcc would be appropriate.
[Bug c/95379] Don't warn about the universal zero initializer for a structure with the 'designated_init' attribute.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #5 from Tom Tromey ---
(In reply to Asher Gordon from comment #3)
> It seems that Sparse's behavior is the same as GCC's. It warns on '{ 0 }'.
> (Note that in Sparse, the attribute must be specified after the closing
> brace.)
Since this warning is intended to work like sparse, introducing
a divergence here would seem to make the feature less useful,
in fact subverting the point of having it.
[Bug debug/83935] DWARF for a variant part is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 Tom Tromey changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |INVALID --- Comment #11 from Tom Tromey --- I'm fully on board with the GCC approach here, and I think this is something that should be changed in the DWARF standard. And, there's a DWARF bug for it. And finally, I have some patches to teach gdb to understand the GCC output here. So, I'm closing this as invalid.
[Bug debug/93988] invalid DWARF emitted for complex integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93988 --- Comment #2 from Tom Tromey --- (In reply to Richard Biener from comment #1) > I wonder if there is (or should be) sth like DW_ATE_unsupported ... using > DW_ATE_lo_user is indeed unfortunate but not wrong per-se. Adding > a DW_ATE_GNU_complex_int might be also possible (and support that from gdb). > > So I'm not sure it's invalid DWARF. It's just colliding vendor extensions > (can gdb "switch" extensions if there are colliding ones? does gdb > autodetect > vendors?) Yeah, "invalid" was the wrong word to use. More like, "undocumented gcc extension"; but one where the output can't really be used. Consider: _Complex int x = 23i; _Complex unsigned int y = 24i; Here the base types can't readily be distinguished: <1><31>: Abbrev Number: 3 (DW_TAG_base_type) <32> DW_AT_byte_size : 8 <33> DW_AT_encoding: 128 (HP_float80) <34> DW_AT_name: (indirect string, offset: 0x0): complex int ... <1><4c>: Abbrev Number: 3 (DW_TAG_base_type) <4d> DW_AT_byte_size : 8 <4e> DW_AT_encoding: 128 (HP_float80) <4f> DW_AT_name: (indirect string, offset: 0x11): __unknown__ These have the same size and encoding, but in reality are different. Also, I see the "__unknown__" there now -- better IMO to let gdb synthesize a name instead. To answer your questions, yes gdb can "vendor sniff" to see what extension to use. This isn't desirable but is done on occasion. Right now gdb doesn't use any of the DW_ATE_HP_* extensions, so even that wouldn't need to be done. However -- the code already needs to be changed, as shown above. And if one is doing that, one might as well avoid a clash and document the extension anyhow.
[Bug debug/93988] New: invalid DWARF emitted for complex integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93988 Bug ID: 93988 Summary: invalid DWARF emitted for complex integer 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: --- Consider this test case: _Complex int x = 23i; Compile with -g and examine the resulting DWARF: <1><31>: Abbrev Number: 3 (DW_TAG_base_type) <32> DW_AT_byte_size : 8 <33> DW_AT_encoding: 128 (HP_float80) <34> DW_AT_name: (indirect string, offset: 0x0): complex int I was surprised to see that "HP_float80" here, but it turns out that this is just an artifact of dwarf.def claiming: /* HP extensions. */ DW_ATE (DW_ATE_HP_float80, 0x80) /* Floating-point (80 bit). */ In reality what gcc is doing is just returning: /* Dwarf2 doesn't know anything about complex ints, so use a user defined type for it. */ case COMPLEX_TYPE: if (TREE_CODE (TREE_TYPE (type)) == REAL_TYPE) encoding = DW_ATE_complex_float; else encoding = DW_ATE_lo_user; break; There are a couple of ways this could be replaced. One would be to give a complex base type its own DW_AT_type, holding the underlying element type. Another would be to pick a range, like 0xa0-0xaf, and emit a value like 0xa0 | DW_ATE_signed. I see in base_type_die that there are other cases that return DW_ATE_lo_user. These are probably also bugs.
[Bug c++/93458] ICE using coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93458 --- Comment #4 from Tom Tromey --- > BTW, did you include ? > > (FAOD: it would still be broken if you did, but ISTM we might at some point > add a hint that if the traits can't be found, you probably forgot that). The code was exactly as written, though IIRC including still yielded the ICE.
[Bug c/93472] New: Document extended forms of constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93472 Bug ID: 93472 Summary: Document extended forms of constant expression Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- GCC accepts extended forms of constant expression. An example that came up recently was: const int a = 5; const int b = a; IIUC the standard permits the compiler to accept other forms of constant expression. However, I couldn't find this in the documentation, and I think it would be good if GCC documented the extensions it supports. Perhaps a new node in the "C Implementation-Defined Behavior" section would be appropriate.
[Bug c++/93458] ICE using coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93458 Tom Tromey changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #1 from Tom Tromey --- I think it's invalid.
[Bug c++/93458] New: ICE using coroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93458
Bug ID: 93458
Summary: ICE using coroutines
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I'm using git master gcc from today.
I tried a simple coroutine program:
int func(int *x) {
for (int i = 0; i < 23; ++i)
co_yield x[i];
}
Compiling causes gcc to ICE:
murgatroyd. ./install/bin/g++ -fcoroutines -g -c -o /tmp/qq.o /tmp/qq.cc
/tmp/qq.cc: In function ‘int func(int*)’:
/tmp/qq.cc:3:5: error: cannot find ‘coroutine traits’ template
3 | co_yield x[i];
| ^~~~
/tmp/qq.cc:3:17: internal compiler error: in coro_promise_type_found_p, at
cp/coroutines.cc:390
3 | co_yield x[i];
| ^
0x5ff2fd coro_promise_type_found_p
../../gcc/gcc/cp/coroutines.cc:390
0x94aeae finish_co_yield_expr(unsigned int, tree_node*)
../../gcc/gcc/cp/coroutines.cc:862
0xa163a0 cp_parser_yield_expression
../../gcc/gcc/cp/parser.c:26176
0xa163a0 cp_parser_assignment_expression
../../gcc/gcc/cp/parser.c:9816
0xa1668d cp_parser_expression
../../gcc/gcc/cp/parser.c:9992
0xa19498 cp_parser_expression_statement
../../gcc/gcc/cp/parser.c:11633
0xa250e3 cp_parser_statement
../../gcc/gcc/cp/parser.c:11429
0xa45c36 cp_parser_already_scoped_statement
../../gcc/gcc/cp/parser.c:13198
0xa45f24 cp_parser_iteration_statement
../../gcc/gcc/cp/parser.c:12848
0xa25154 cp_parser_statement
../../gcc/gcc/cp/parser.c:11298
0xa26792 cp_parser_statement_seq_opt
../../gcc/gcc/cp/parser.c:11780
0xa26868 cp_parser_compound_statement
../../gcc/gcc/cp/parser.c:11730
0xa3f085 cp_parser_function_body
../../gcc/gcc/cp/parser.c:22963
0xa3f085 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/gcc/cp/parser.c:23014
0xa42421 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:28846
0xa431c1 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:28762
0xa431c1 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:20590
0xa22eb3 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13669
0xa4b197 cp_parser_declaration
../../gcc/gcc/cp/parser.c:13368
0xa4b917 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4731
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug c/57612] add builtin to assert that expression does not have side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57612 --- Comment #4 from Tom Tromey --- (In reply to H. Peter Anvin from comment #2) > I would like to second this request, however, I would like to request that > it issues a warning rather than an error. It can always be promoted to an > error via -Werror= or the equivalent pragma. What's the use case for this? It seems simpler to just not use this macro when you don't want the effect. (In reply to felix from comment #3) > Overlaps bug 6906. Under that ticket, I proposed adding a built-in that > simply returns whether or not a given expression has side effects, simply by > exposing TREE_SIDE_EFFECTS(). This seems the same to me, in that __builtin_assert_no_side_effects could, I think, just be a static_assert using your builtin.
[Bug other/61257] configure should check if sys/sdt.h is usable, not just checking the existance of the header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61257 --- Comment #6 from Tom Tromey --- (In reply to Eric Gallager from comment #4) > (In reply to Sergei Trofimovich from comment #3) > > (In reply to Sergei Trofimovich from comment #2) > > > Having explicit flags like --enable-systemtap / --disable-systemtap (glibc > > > has those) would fix the issue. > > > > Proposed upstream as: > > https://gcc.gnu.org/ml/gcc-patches/2018-05/msg00578.html > > > > To clarify: it's not a complete fix for this bug. Only a way to disable > > support manually. > > I'll take this as confirmation. Also now that I've seen the actual code in > this patch, I can say that my previous comment (comment #1) no longer > applies, since the script is just doing `test -f` instead of > AC_CHECK_HEADERS. IIRC that's because it has to check target headers, but AC_CHECK_HEADERS checks host headers. Maybe there's some other way to do it, I don't know. It's fine to really check the header, but I would say the scenario in comment #2 has to fall under "don't do this". That said, a --enable flag or whatever also seems fine to me.
[Bug debug/91411] New: Extraneous size & location attributes for members in DWARF
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91411
Bug ID: 91411
Summary: Extraneous size & location attributes for members in
DWARF
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: ---
Consider this test case:
struct x
{
int a : 5;
int b : 2;
};
struct x x;
Compile with -g -c and then examine the DWARF.
For x::a, I get:
<2><28>: Abbrev Number: 3 (DW_TAG_member)
<29> DW_AT_name: a
<2b> DW_AT_decl_file : 1
<2c> DW_AT_decl_line : 3
<2d> DW_AT_decl_column : 7
<2e> DW_AT_type: <0x45>
<32> DW_AT_byte_size : 4
<33> DW_AT_bit_size: 5
<34> DW_AT_bit_offset : 27
<35> DW_AT_data_member_location: 0
This has two minor bugs.
First, DWARF 5 section 5.7.6 ("Data Member Entries") says:
The member entry corresponding to a data member that is defined in a structure,
union or class may have either a DW_AT_data_member_location attribute or a
DW_AT_data_bit_offset attribute.
I think that is an exclusive "or", meaning that having both attributes
is incorrect.
Second, the same section says:
If the size of a data member is not the same as the size of the type given for
the
data member, the data member has either a DW_AT_byte_size or a
DW_AT_bit_size attribute whose integer constant value (see Section 2.19 on
page 55) is the amount of storage needed to hold the value of the data member.
Again, to me this indicates that GCC should only emit one of the two
attributes.
[Bug jit/91330] JIT "dir" entry for info is incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91330
--- Comment #1 from Tom Tromey ---
This is pretty easy to fix in gcc/jit/docs/conf.py:
diff --git a/gcc/jit/docs/conf.py b/gcc/jit/docs/conf.py
index 3e630db47ef..1224bdcc07d 100644
--- a/gcc/jit/docs/conf.py
+++ b/gcc/jit/docs/conf.py
@@ -244,7 +244,7 @@ man_pages = [
# dir menu entry, description, category)
texinfo_documents = [
('index', 'libgccjit', u'libgccjit Documentation',
- u'David Malcolm', 'libgccjit', 'One line description of project.',
+ u'David Malcolm', 'libgccjit', 'GCC-based Just In Time compiler library.',
'Miscellaneous'),
]
However, I don't have the version of sphinx that was used to generate
the docs, and when I run the version I do have, there are tons of changes.
So, maybe someone else ought to do this part.
[Bug jit/91330] New: JIT "dir" entry for info is incomplete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91330 Bug ID: 91330 Summary: JIT "dir" entry for info is incomplete Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- Looking at the "dir" entry for the JIT, I see: murgatroyd. grep jit install/share/info/dir * libgccjit: (libgccjit.info). One line description of project. I think the "One line description..." text should be replaced with something more descriptive.
[Bug c++/90526] New: Missing DW_AT_const_value for constexpr field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90526
Bug ID: 90526
Summary: Missing DW_AT_const_value for constexpr field
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
This test case comes from https://sourceware.org/bugzilla/show_bug.cgi?id=20020
Consider:
template
struct foo
{
static constexpr bool is_always_lock_free = true;
};
int main()
{
foo p;
return 0;
}
Using a recent trunk gcc: gcc (GCC) 10.0.0 20190515 (experimental),
compiling with -g, and looking at the DWARF, I see this DIE for
foo::is_always_lock_free:
<2><3a>: Abbrev Number: 3 (DW_TAG_member)
<3b> DW_AT_name: (indirect string, offset: 0x0):
is_always_lock_free
<3f> DW_AT_decl_file : 1
<40> DW_AT_decl_line : 4
<41> DW_AT_decl_column : 25
<42> DW_AT_type: <0x57>
<46> DW_AT_external: 1
<46> DW_AT_declaration : 1
<46> DW_AT_const_expr : 1
Notice no DW_AT_const_value.
However, I change foo to not be a template, I get:
<2><3a>: Abbrev Number: 3 (DW_TAG_member)
<3b> DW_AT_name: (indirect string, offset: 0x15):
is_always_lock_free
<3f> DW_AT_decl_file : 1
<40> DW_AT_decl_line : 3
<41> DW_AT_decl_column : 25
<42> DW_AT_type: <0x4f>
<46> DW_AT_external: 1
<46> DW_AT_declaration : 1
<46> DW_AT_const_value : 1
<47> DW_AT_const_expr : 1
I think the template case should also emit a const_value
[Bug tree-optimization/90427] New: missing "sign flipping" optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90427
Bug ID: 90427
Summary: missing "sign flipping" optimization
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
This test case comes from this blog post:
https://nfrechette.github.io/2019/05/08/sign_flip_optimization/
(which also says that clang 8 performs this optimization).
Consider
float foo_ref(float value) {
value = value * 0.5f; // mulss value, 0.5f
// movss tmp, 1.0f
return 1.0f - value;// subss tmp, value
}
float foo_ref2(float value) {
value = value * -0.5f; // mulss value, -0.5f
return value + 1.0f; // addss value, 1.0f
}
According to the post, these are equivalent. However, gcc
generates different code for them, with the latter being better.
The comments for the first function seem to omit an
instruction that gcc emits, making that version even worse:
movss .LC0(%rip), %xmm1
mulss %xmm0, %xmm1
movss .LC1(%rip), %xmm0
subss %xmm1, %xmm0
However the comments in the second one are correct:
mulss .LC2(%rip), %xmm0
addss .LC1(%rip), %xmm0
Tested with git master from today, using gcc -O2, on x86-64 Fedora 29.
I just made a guess at which component to use.
[Bug debug/83935] DWARF for a variant part is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #10 from Tom Tromey --- I have been looking at this again recently, for Ada, and now I think perhaps the approach that GCC takes should be preferred. At first I was thinking maybe the compiler could linearize the members of the emitted structure, but I tried modifying the example in comment #2 to add multiple variants with different discriminators: package Pck is type Rec (I : Integer; J: Integer) is record case I is when Positive => C : Character; case J is when 0 => null; when others => N : Natural; end case; when others => S : String (1 .. 10); end case; end record; R : Rec (1, 2); end Pck; ... this seems to work and I think means that nested variant parts is indeed a sensible way to go.
[Bug c++/89854] New: diagnostic differences between misuse of "." and "->"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89854
Bug ID: 89854
Summary: diagnostic differences between misuse of "." and "->"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I'm using the system gcc on Fedora 29:
gcc (GCC) 8.2.1 20180801 (Red Hat 8.2.1-2)
Consider this source:
struct s {
int f;
};
int x(struct s s) {
return s->f;
}
int x(struct s *s) {
return s.f;
}
Compiling it with g++:
murgatroyd. g++ --syntax-only b.cc
b.cc: In function ‘int x(s)’:
b.cc:6:11: error: base operand of ‘->’ has non-pointer type ‘s’
return s->f;
^~
b.cc: In function ‘int x(s*)’:
b.cc:10:12: error: request for member ‘f’ in ‘s’, which is of pointer type ‘s*’
(maybe you meant to use ‘->’ ?)
return s.f;
^
Notice that the "->" message underlines the operator (which seems best
to me), whereas the "." message underlines the member.
Also notice that the "." message suggests using "->" (which seems best
to me), whereas the "->" message does not.
Finally, it seems to me that both of these could provide fixits.
[Bug c++/89818] New: possibly invalid name mangling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89818 Bug ID: 89818 Summary: possibly invalid name mangling Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- Apologies for the vagueness of this bug. I ran across a pull request that mentions that gcc will sometimes emit an erroneous 'sr' mangling: https://github.com/gimli-rs/cpp_demangle/pull/173 In particular that bug claims that gcc can emit this symbol, which it further claims is invalid: _ZN4base8internal14CheckedSubImplIlEENSt9enable_ifIXsrSt14numeric_limitsIT_E10is_integerEbE4typeES4_S4_PS4_ I don't know whether these claims are accurate, but I figured it would be worth filing, just in case.
[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635 --- Comment #14 from Tom Tromey --- (In reply to Jonathan Wakely from comment #8) > Something like __builtin_unreachable() to say "trust me" would be nice, but > I can't think how to do it. How about an attribute that can be attached to the member? Then tree-ssa-uninit could check for this and suppress the warning.
[Bug c/64862] printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862 --- Comment #10 from Tom Tromey --- Also I think all the test suite changes never really worked.
[Bug c/64862] printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862 --- Comment #9 from Tom Tromey --- Created attachment 45413 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45413=edit ancient patch
[Bug c/64862] printf attribute should accept other string types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862 --- Comment #8 from Tom Tromey --- Sorry about the extreme delay on this. I think my patch has long since bit-rotted, but I can attach it for reference. I believe my assignment situation got sorted out so this should be fine to read and/or copy from.
[Bug c++/88520] New: improve warning when `struct` is required
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88520
Bug ID: 88520
Summary: improve warning when `struct` is required
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Consider this source:
int Foo;
struct Foo
{
int a;
};
extern int f(Foo x);
gcc (I'm using 8.2.1 from Fedora 28) says:
q.cc:8:14: warning: ‘f’ initialized and declared ‘extern’
extern int f(Foo x);
^~~
q.cc:8:17: error: expected ‘)’ before ‘x’
extern int f(Foo x);
~ ^~
)
clang is somewhat nicer here, showing where the definition appeared.
This is handy info for figuring out what went wrong:
q.cc:8:14: error: must use 'struct' tag to refer to type 'Foo' in this scope
extern int f(Foo x);
^
struct
q.cc:1:5: note: struct 'Foo' is hidden by a non-type declaration of 'Foo' here
int Foo;
^
This came up on the gdb list, where a user couldn't figure out why
gcc was erroring.
[Bug c/65158] printf attribute error reporting assumes single-byte characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65158 Tom Tromey changed: What|Removed |Added Status|WAITING |REOPENED --- Comment #2 from Tom Tromey --- (In reply to Martin Sebor from comment #1) > There is no format specifier in C or POSIX that involves a multibyte > character. They're all single byte characters in the 7-bit ASCII range that > should convert to single byte characters in most (all?) encodings. It would > take an unusual character set to map a 7-bit character to a multibyte > sequence. Is it worth worrying about this corner case? I think this is just a bug I noticed by inspection. The issue is that if the user typo the source somehow, gcc will print something invalid. So, yes, minor; but nevertheless a bug. I'm reopening on that basis.
[Bug target/87104] missed &, == optimization makes Emacs ~0.4% slower on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87104 --- Comment #13 from Tom Tromey --- (In reply to pipcet from comment #12) > So I think the performance difference is really significant for Emacs; my > plan is to test all three versions on other programs, make sure the code > works for C bitfields, and then submit it for inclusion. Is that okay? Just as a process comment, you're not too likely to get an answer to this sort of question; instead just go ahead and send the patch and see what the responses are. Thanks for looking into this.
[Bug c++/87062] mis-optimized code with -O3 and std::pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87062 --- Comment #1 from Tom Tromey --- Analysis in the comments there puts the blame on -ftree-slp-vectorize
[Bug c++/87062] New: mis-optimized code with -O3 and std::pair
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87062
Bug ID: 87062
Summary: mis-optimized code with -O3 and std::pair
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I'm filing this on behalf of someone who posted this bug on reddit.
https://www.reddit.com/r/cpp/comments/99e1ri/interesting_gcc_optimizer_bug/
Copying text from there:
Looks like there is an interesting gcc optimizer bug in gcc 7+.
#include
std::pair fret(long i) { return {i, i}; }
With -O2 gcc generates the expected:
mov rdx, rdi
mov rax, rdi
But with -O3 it generates:
mov QWORD PTR [rsp-24], rdi
movqxmm0, QWORD PTR [rsp-24]
punpcklqdq xmm0, xmm0
movaps XMMWORD PTR [rsp-24], xmm0
mov rax, QWORD PTR [rsp-24]
mov rdx, QWORD PTR [rsp-16]
https://godbolt.org/z/lXoaA4
[Bug jit/87003] use nonnull attribute in libgccjit.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87003 --- Comment #2 from Tom Tromey --- I don't really know the best thing to do. I see your point about graceful failure being a useful feature, in cases where the result of some gcc-jit function is passed as an argument to another one. Maybe there are some arguments that truly cannot be NULL? If any exist I think it would be fine to mark them as nonnull and have the implementation simply assert. Perhaps there aren't many of these though. Another thing that would be useful would be a section in the manual explaining the null-handling approach. I see there is some text about this but perhaps it could be made more prominent, like having a whole section just dedicated to this topic?
[Bug jit/87005] New: gcc_jit_context_get_builtin_function not documented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87005 Bug ID: 87005 Summary: gcc_jit_context_get_builtin_function not documented Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- The function gcc_jit_context_get_builtin_function is not documented.
[Bug jit/87004] New: no way to mark a function as noreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87004 Bug ID: 87004 Summary: no way to mark a function as noreturn Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- Currently all blocks must be terminated either with a jump or a return. I think it should also be possible to terminate a block with a call to a noreturn function. But, there is no way to indicate that a function is noreturn.
[Bug jit/87003] New: use nonnull attribute in libgccjit.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87003 Bug ID: 87003 Summary: use nonnull attribute in libgccjit.h Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- Many functions in libgccjit.h take a pointer argument, and it isn't clear which of these can be NULL and which cannot. It would be a bit helpful if the nonnull attribute were applied where appropriate.
[Bug jit/87002] New: allow integers larger than "long"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87002 Bug ID: 87002 Summary: allow integers larger than "long" Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- gcc-jit has gcc_jit_context_new_rvalue_from_int and gcc_jit_context_new_rvalue_from_long, but on some platforms long might be 32 bits, but a program could still use int64_t or long long. I think gcc-jit should have an intmax_t function, and perhaps uintmax_t as well.
[Bug bootstrap/84402] [meta] GCC build system: parallelism bottleneck
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402 --- Comment #17 from Tom Tromey --- The results in comment #13 seem to be missing some compilations -- I would have expected to see more files from libcpp in there. As it is I only see directives.o and line-map.o.
[Bug debug/83935] DWARF for a variant part is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #9 from Tom Tromey --- (In reply to Pierre-Marie de Rodat from comment #8) > Understood, thank you for the notice! As we have to tweak the spec one way > or another for Ada, I suggest indeed we keep the way things are implemented > in GCC today, waiting for the DWARF committee to state on this. This will > probably take a while, so I’m not sure what to do with this PR. ;-) I suppose we could leave it open pending resolution. > Can you please tell me when you managed to update GDB to work with variant? > It could be interesting to see how it deals with GCC’s, and if it does not, > how much work will be needed. Thank you in advance! It is here: https://github.com/tromey/gdb/tree/variant-parts I plan to submit it to gdb soon, like probably today. There are 3 patches; the first one introduces some minor changes to add discriminated unions to gdb's type system, and the third one adds the DWARF reading parts. I imagine there are some gaps between what I did and what Ada requires. Since I don't know Ada I'm not really sure how big the gaps are. I'd suggest reading it, then commenting on the gdb-patches post so that it can be discussed there. Dealing with the particular location of the discriminant might not be too awful. One simple idea would be to make a new artificial discriminant in the discriminated union, essentially copying the member from the outer struct. There are two missing bits I know about: one is that I didn't need DW_AT_discr_list, so I didn't add this. This should be straightforward. The other is that in Rust, a variant can only have a single member. Multiple members could be dealt with in the current model by interposing a new anonymous structure type, perhaps.
[Bug debug/83935] DWARF for a variant part is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #7 from Tom Tromey --- For Rust I ended up following the letter of the standard, so I'm going to follow this in the gdb patches as well. That said, gdb can be adapted to work with either approach, so it's not strictly necessary to change gcc here, perhaps depending on resolution of that DWARF issue.
[Bug debug/83935] DWARF for a variant part is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 --- Comment #3 from Tom Tromey --- (In reply to Pierre-Marie de Rodat from comment #2) > Thinking more about it, the rule that the discriminant entry must be a child > of the variant part entry sounds suspicious to me. TBH this did not make sense to me, either, which is partly why I originally wrote my patch the "more natural" way -- then this got caught in review, see https://reviews.llvm.org/D42082 > I guess I should report these questions to the DWARF discussion mailing > list. What do you think, Tom? It's worth a shot, though I think it was tried before, see http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2006-August/001710.html
[Bug ada/83935] New: DWARF for a variant part is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935 Bug ID: 83935 Summary: DWARF for a variant part is incorrect Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- Joel Brobecker sent me an Ada test case so that I could see a real-life example of the use of DW_TAG_variant_part (in support of some Rust stuff I'm doing elsewhere). For this test case, GCC emits this DWARF: <1><7c0>: Abbrev Number: 4 (DW_TAG_structure_type) <7c1> DW_AT_name: (indirect string, offset: 0xb26): pck__rec <7c5> DW_AT_byte_size : 13 byte block: 97 94 1 99 95 0 0 0 23 7 9 fc 1a <7d3> DW_AT_decl_file : 2 <7d4> DW_AT_decl_line : 15 <7d5> DW_AT_sibling : <0x817> <2><7d9>: Abbrev Number: 5 (DW_TAG_member) <7da> DW_AT_name: (indirect string, offset: 0xaf8): discr <7de> DW_AT_decl_file : 2 <7df> DW_AT_decl_line : 15 <7e0> DW_AT_type: <0x7af> <7e4> DW_AT_data_member_location: 0 <2><7e5>: Abbrev Number: 6 (DW_TAG_variant_part) <7e6> DW_AT_discr : <0x7d9> <3><7ea>: Abbrev Number: 7 (DW_TAG_variant) <7eb> DW_AT_discr_value : 1 <7ec> DW_AT_sibling : <0x7fd> However, the DWARF standard says: > If the variant part has a discriminant, the discriminant is represented > by a separate debugging information entry which is a child of the variant > part entry. So, I think that, according to the DWARF standard, that "discr" member must be a child (not a sibling) of the DW_TAG_variant_part.
[Bug c++/61414] enum class bitfield size-checking failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414 --- Comment #10 from Tom Tromey --- I ran into this again, went to file a bug, and then found that I'd already filed the bug...
[Bug c++/81431] add warning for missing initializers in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81431 --- Comment #1 from Tom Tromey --- Also related is bug 55837.
[Bug c++/81431] New: add warning for missing initializers in constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81431
Bug ID: 81431
Summary: add warning for missing initializers in constructor
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I would like gcc to emit a warning when a constructor does not
initialize a POD member; and in particular I'd like this not to
be tied to -Wuninitialized.
Having a warning like this is good for robustness -- it avoids
situations where one forgets to initialize a scalar or the like.
I realize -Wuninitialized will do this, but that can be a difficult
warning to enable for an existing code base, due to false positives.
Something along the lines of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2972#c9
would be nice.
-Weffc++ does warn about this, but it is too broad, as it includes
members that have a constructor.
Here's a simple example:
struct X
{
int a,b;
X() : a(5) { }
};
X x;
[Bug c++/80712] New: mention the name of the attribute being ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80712 Bug ID: 80712 Summary: mention the name of the attribute being ignored Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- I saw an error when building firefox with gcc 6.3.1 (fedora 25 system gcc): /home/tromey/firefox-git/gecko/js/src/frontend/EitherParser.h:253:13: error: ignoring attributes applied to ‘__va_list_tag’ after definition [-Werror=attributes] You can see more info here: https://bugzilla.mozilla.org/show_bug.cgi?id=1363116 I don't know what attribute might be applied here. It would be handy if gcc mentioned which attribute it was ignoring. (FWIW I am not sure but I suspect this error might be a gcc bug.)
[Bug c++/79531] New: bad location when trying to define undeclared method
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79531
Bug ID: 79531
Summary: bad location when trying to define undeclared method
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Consider this source:
===
struct base {
virtual void m() = 0;
};
struct derived : public base {
virtual void m() override;
virtual void method2() override;
};
void derived::n ()
{
}
===
This has two errors -- one that "method2" is declared override but doesn't
in fact override; and two that "n" is defined but not declared in the class.
Compiling with g++ gives:
bapiya. g++ -c x.cc
g++ -c x.cc
x.cc:7:16: error: ‘virtual void derived::method2()’ marked ‘override’, but does
not override
virtual void method2() override;
^~~
x.cc:10:18: error: no ‘void derived::n()’ member function declared in class
‘derived’
void derived::n ()
^
For "method2" the location is where I'd expect.
However, for "n" the location comes after the close parens.
I think the "n" case should use the location of the identifier "n",
like the "method2" case does.
I'm using the system gcc on Fedora 25:
bapiya. gcc --version
gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
[Bug debug/77315] emit DW_OP_form_tls_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77315 Tom Tromey changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #3 from Tom Tromey --- Fixed.
[Bug debug/77315] emit DW_OP_form_tls_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77315 --- Comment #2 from Tom Tromey --- Author: tromey Date: Mon Oct 31 20:08:44 2016 New Revision: 241721 URL: https://gcc.gnu.org/viewcvs?rev=241721=gcc=rev Log: PR debug/77315: * dwarf2out.c (mem_loc_descriptor): Use DW_OP_form_tls_address. (resolve_args_picking_1): Move DW_OP_form_tls_address case next to DW_OP_GNU_push_tls_address case. (loc_list_from_tree_1): Use DW_OP_form_tls_address. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c
[Bug debug/77315] emit DW_OP_form_tls_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77315 Tom Tromey changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tromey at gcc dot gnu.org --- Comment #1 from Tom Tromey --- Testing a patch.
[Bug c++/78014] -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014 --- Comment #3 from Tom Tromey --- (In reply to jos...@codesourcery.com from comment #2) > Likewise an expression where the user did "typedef size_t my_size_t;" and > then used my_size_t. And what about expressions resulting from arithmetic > on size_t values? So it may be hard for the compiler to tell exactly what > expressions are appropriate for use with %zu (even without direct use of > __SIZE_TYPE__). I think it's still preferable for gcc to be better about this even if it can't be perfect. First, in my particular case, I think all the types in question are just "size_t" -- it's common to use this in spidermonkey. Second, the problem I have is that I wanted to enable -Wformat. So, I wrote a bunch of patches -- which then failed to build on other arches. In this case, if gcc had warned about size_t/%lu mixups in the code, while perhaps I wouldn't have caught every possible cross-arch build bug, I certainly would have far fewer of them.
[Bug c++/78014] New: -Wformat -vs- size_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78014
Bug ID: 78014
Summary: -Wformat -vs- size_t
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Compile this test program with -Wformat:
#include
int main() {
size_t x = 0;
printf("got %lu\n", x);
}
I expected this to give a warning, because the correct format should
be %zu. %lu happens to be correct on this machine, but on a 32-bit
machine it is not.
[Bug c++/77958] New: printf format checking -vs- variadic template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77958
Bug ID: 77958
Summary: printf format checking -vs- variadic template
functions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Consider this test case, derived from code I found in firefox:
#include
#include
template
static void
// __attribute__ ((format (printf, 1, 2)))
whatever(const char *fmt, Args&&... args)
{
printf(fmt, args...);
}
void qq()
{
whatever("hi %d", "bob");
}
If I compile this with -Wformat, I don't get any warnings.
However, if I uncomment the __attribute__, I get:
pokyo. g++ -Wall -c -Wformat q.cc
q.cc: In substitution of ‘template void whatever(const char*,
Args&& ...) [with Args = {const char (&)[4]}]’:
q.cc:14:26: required from here
q.cc:7:1: error: args to be formatted is not ‘...’
whatever(const char *fmt, Args&&... args)
^~~~
I think the attribute approach ought to work.
[Bug debug/77315] New: emit DW_OP_form_tls_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77315 Bug ID: 77315 Summary: emit DW_OP_form_tls_address 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: --- Currently gcc generally emits DW_OP_GNU_push_tls_address for the location of a thread-local. However, it seems to me that the standard DW_OP_form_tls_address is equivalent but slightly better due to being standard. Note though that gdb generally doesn't implement the standard form, so that would have to be done first. See https://sourceware.org/bugzilla/show_bug.cgi?id=11616
[Bug c++/72789] New: add -Wunused-private-field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72789 Bug ID: 72789 Summary: add -Wunused-private-field Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Target Milestone: --- I found out recently that clang has a '-Wunused-private-field' warning. E.g., I got: https://github.com/mozilla/rr/pull/1757#issuecomment-237031428 I think it would be good to add this to gcc.
[Bug c/71852] New: add warning for conditions that can never be true
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71852
Bug ID: 71852
Summary: add warning for conditions that can never be true
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: ---
Consider this code, derived from some code in gdb's arm-tdep.c:
int main(int argc, char**argv)
{
unsigned int aa = argc;
aa = aa & 0x04;
if (aa == 0x00) {
// Ok.
} else if (aa == 0x01) {
// Ok.
} else if (aa == 0x0b) {
// Oops.
}
}
Here, two of the conditions can never be true.
I think it would be nice if gcc could warn for this case.
