[Bug debug/78322] Debug info still present for fully optimized away functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78322 --- Comment #5 from David Blaikie --- (In reply to Andrew Pinski from comment #4) > (In reply to David Blaikie from comment #2) > > (In reply to Richard Biener from comment #1) > > > We produce an abstract copy for use by repeated inline copies. > > > > Yep! Is it still reasonable to consider it a bug (or at least a feature > > request) that this is still produced even when no inline copies are emitted? > > Not really. > > Sounds like what you are aiming for is the nodebug attribute that you can > use with always_inline. Basically in dwarf inline functions are still > represented as functions (calls) and most folks want that for their > debugability of their program but in this case you specific inlined > functions not to have debug info which is exactly what nodebug would do ... Not sure I follow. I'm not suggesting this function should be `nodebug`. Specifically: If an abstract origin is unreferenced, it seems like it should/could be omitted, for brevity. If the abstract origin is referenced - if there was some remnant of the inlined code that then caused an inlined_subroutine to be emitted, that would need to reference the abstract origin and so the latter should be emitted. This is what clang does, at least - thought it might be nice for gcc to do that to, to have more compact DWARF output. https://godbolt.org/z/3doWWK4G4 (though, interestingly, since this bug was filed - in GCC 9, GCC started putting NOPs in for the inlined code, which is a nice touch - so at -O0 you can still step into/out of a no-op (or presumably otherwise optimized away? if you had some optimizations forced on at -O0 somehow) inlined function - but with optimizations enabled you still see the behavior of an abstract origin emitted without any uses/references to it)
[Bug debug/99178] Emit .debug_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178 --- Comment #6 from David Blaikie --- (In reply to Tom Tromey from comment #5) > (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. Certainly what's been possible with .debug_gnu_pubnames/types + -Wl,--gdb-index today. It'd be nice to have that same workflow, but in a more portable form. > > 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 Ah, thanks for the link - I followed up there with some context/thoughts. > 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). 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. > Also, gdb relies on its extensions (see below). Ah, but yeah, if you need extensions, then positive augmentation string checking seems likely necessary. (though this starts to feel like websites checking browser versions, unfortunately :/ ) > 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). No worries - and totally understandable. If they happen to come to mind at any point, I'd love to hear about them. > 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 Awesome - appreciate the documentation! > 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. Yeah, I'd love to figure out how to deal with that better, but don't have immediate suggestions. 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? Is that something that'd be an option? (especially with a flag in the entry, then it'd only be a runtime cost to those using this naming mechanism - as much as I'd like to move to that mechanism being normal/the default, perhaps this would be a safe transition path) But I guess Google's probably the only one super interested in the simplified template names at the moment (& we're mostly investing in lldb these days), so might be unlikely anyone would be signing up to do that work in gdb. > 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 Oh, that's got some good details/answers some of my questions - thanks! > I consider this hash table to be essentially useless in general, due to the > name canonicalization problem -- while DWARF says that writers should use the > system demangling style, (1) this style varies across systems, so it can't > truly be relied on; and (2) at least GCC and one other compiler don't > actually follow this part of the spec anyway. 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"? > It's important to note, though, that even if the hash was somehow useful, GDB > probably still would not use it -- a sorted list of names is needed for > completion and performs reasonably well for other lookups, so a hash table is > just overhead, IMO. Oh, that makes loa
[Bug debug/99178] Emit .debug_names
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178 David Blaikie changed: What|Removed |Added CC||dblaikie at gmail dot com --- Comment #4 from David Blaikie --- (In reply to Mark Wielaard from comment #3) > So if the compiler would emit the .debug_name index would that make any > link/post-processing steps easier or more efficient? Right - that's the intent. You can omit the hash table part of .debug_names - in which case it's just like a newer pubnames/pubtypes - maybe with the opportunity to have more guaranteed contents (the lack of those guarantees I think is why debug_gnu_pubnames/types came to be, yeah?). At least on the lld side, we're working on adding the requisite merging - like `-Wl,--gdb-index`, except instead of merging debug_gnu_pubnames/pubtypes -> gdb_index, it merges debug_names -> debug_names. This is relevant/important/necessary for Split DWARF in particular, where the linker wouldn't have access to the DWARF to index it anyway (& you don't always want to run the dwp tool, which would have access to all the DWARF to index it - but it'd be nice to avoid that in iterative developer scenarios, and save it only for archival situations) - and even if you do have all the DWARF, it's certainly faster to merge some tables than to reparse all the DWARF from scratch. 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.
[Bug c++/109114] New: lambdas should be non-pod for ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109114
Bug ID: 109114
Summary: lambdas should be non-pod for ABI
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dblaikie at gmail dot com
Target Milestone: ---
See original bug filed against clang:
https://github.com/llvm/llvm-project/issues/59078
itanium-cxx-abi bug: https://github.com/itanium-cxx-abi/cxx-abi/issues/156
(inverted, so it fails with GCC and passes with Clang) example from the clang
bug: https://godbolt.org/z/45TxsPehe
```
template
struct Callables : T ... {
Callables(T ...t) : T(t) ... {}
using T::operator() ...;
};
inline auto f(int x, char y) {
Callables callables([x, y](void) {}, [y](int) {});
static_assert(sizeof(callables) == 8);
return callables;
}
int main(void) { f(0, 1)(42); }
```
Maybe still an open question about lambdas that don't capture - since they do
have a default ctor, but the spec still says they're non-aggregate.
[Bug c++/107741] Missed member variable name in mangling of externally visible lambdas used in inline initialization of static members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107741 --- Comment #2 from David Blaikie --- Ping on this? Would love it if someone could check my work/confirm my diagnosis, even if it's not a priority to fix the bug immediately.
[Bug debug/49130] discrepancies between DW_AT_name and demangler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49130 David Blaikie changed: What|Removed |Added CC||dblaikie at gmail dot com --- Comment #12 from David Blaikie --- > Note that both DW_AT_name and DW_TAG_template_value_param are > incorrect. The demangler gets it right: > >void f(S2) Yeah, the problem here is that the /type/ is correctly `S2` - that's the same type no matter how it's written. But the mangling of `f` is distinct depending on how the expression is written... I'm not really sure how we should encode that in DWARF - it'd be problematic to encode a different `S2` instantiation for this context compared to some other place that names the type differently - in terms of the debugger being able to treat them as the same type, match declarations and definitions, etc. I guess S2 could be emitted as an alias/typedef of the underlying S2? Or some other way to carry the mangle-equivalent details on the DW_TAG_template_*_parameter directly? Though these expression template issues only apply to functions, yeah? Is there a need to deduplicate function definitions - generally the linker has already done this & the DWARF describes the function definition - I guess the issue here is that two different functions will have the same DW_AT_name & confuse the debugger/user if they're trying to call the functions in an expression evaluator, etc.
[Bug debug/49312] Make DW_AT_name contain only simple name, no template-id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49312 David Blaikie changed: What|Removed |Added CC||dblaikie at gmail dot com --- Comment #4 from David Blaikie --- FWIW I've (partially) implemented this in Clang under the flag `-gsimple-template-names` due to some really large debug info issues with (especially eigen and tensorflow) expression templates (I saw template names as long as 50k characters leading to exceeding the 32 bit limit in .debug_str.dwo sections in dwp files (and gold dwp didn't check for overflow, so this caused silent corruption)). There certainly are some issues with it - my approach didn't simplify all names - certain names aren't easy to roundtrip from the DIE descriptions of the template parameters (lambdas are a great/difficult example, for instance - the lambda type DIEs don't have anything about the lambda mangling number, etc, and maybe should - so even in non-template cases the lambdas could be matched up between two TUs (lambdas in inline functions are the same type even in different translation units & should be treated as such)) So there's a bunch of work that'd probably need to be done on template DIE accuracy/completeness before this feature could be adopted wholesale without any exemptions, but for the size benefits (especially in expression template heavy code) I've found it to be worthwhile & we've done some work to flesh out support for this in lldb as well as identify maybe a couple of gdb bugs related to this. I've tried to poke dwarf-discuss about the lambda issue in particular ( http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2022-August/007117.html ) but no one seems interested in discussing it. So maybe it's something GCC/Clang/GDB/LLDB folks should discuss more directly together. Also some recent discussion with Simon Marchi on the gdb list: https://sourceware.org/pipermail/gdb/2023-January/050496.html
[Bug c++/107741] Missed member variable name in mangling of externally visible lambdas used in inline initialization of static members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107741 --- Comment #1 from David Blaikie --- Oh, some context - discovered while investigating a related clang bug: https://github.com/llvm/llvm-project/issues/58819 - so don't check clang for an example of what's right here, it has different bugs, though I've sent a fix for that for review.
[Bug c++/107741] New: Missed member variable name in mangling of externally visible lambdas used in inline initialization of static members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107741
Bug ID: 107741
Summary: Missed member variable name in mangling of externally
visible lambdas used in inline initialization of
static members
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dblaikie at gmail dot com
Target Milestone: ---
https://godbolt.org/z/7514cTh5o
```
struct A {
static constexpr auto x = [] {
return 1;
};
};
template
struct B {
static constexpr auto x = [] {
return 1;
};
};
template
struct C {
static int x;
};
void side_effect();
template
int C::x = (side_effect(), [] { return 1; }());
template int C::x;
void f() {
A::x();
B::x();
}
```
GCC produces these manglings:
```
A::{lambda()#1}::operator()() const
_ZNK1AUlvE_clEv
B::{lambda()#3}::operator()() const
_ZNK1BIiEUlvE1_clEv
C::x::{lambda()#1}::operator()() const
_ZNK1CIiE1xMUlvE_clEv
```
I believe in the first two cases, the member variable scope ("::x") is missing.
Oh, and it looks like the lambda numbering is off - B's lambda is 1 within its
scope (either the type or the member) - so I guess that needs to be fixed
too/scoping the numbering to within the member along with the mangling having
that scoping.
[Bug c/89549] [10/11/12/13 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549 --- Comment #26 from David Blaikie --- FWIW I'm not sure it's a pragma I'd want, but it might be sufficient (put the pragma at the start of very long/autogenerated files) - I'd have thought what some folks (myself/LLVM included, I think) is a version of the warning that is "best effort" and otherwise quiet. "Tell me when you know I have misleading indentation, otherwise say nothing" - which is how most warnings work, basically - they all have false negatives.
[Bug debug/60833] Inheritance via typedef skips the typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60833 --- Comment #3 from David Blaikie --- FWIW, bug on the GDB side seems to have been fixed ( https://sourceware.org/bugzilla/show_bug.cgi?id=16841 ) - might be nice to fix the GCC side too. (though, admittedly, I don't know that this extra debug info provides much value at the moment - I think GDB mostly looks straight through typedefs)
[Bug c/89549] [10/11/12/13 Regression] -Wmisleading-indentation is disabled from this point onwards, since column-tracking was disabled due to the size of the code/headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549 David Blaikie changed: What|Removed |Added CC||dblaikie at gmail dot com --- Comment #23 from David Blaikie --- FWIW, the inability to disable this note has caused Clang to disable the warning due to the noise. ( https://reviews.llvm.org/D132914 ) It'd be nice to have a way to enable the warning as "best effort" - knowing that some files are too long to get checking. (but also - it'd be nice if the warning were implemented in such a way that it could scale up to indefinitely long files - it seems like that should be possible to have a scalable implementation of the warning? (at least a version that's linear in the number of lines in the file/or the number of lines in long nested scopes?))
[Bug c++/87729] Please include -Woverloaded-virtual in -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87729 David Blaikie changed: What|Removed |Added CC||dblaikie at gmail dot com --- Comment #7 from David Blaikie --- FWIW, I implemented (or at least tuned) overloaded-virtual in Clang - it doesn't quite match GCC's behavior. (specifically it doesn't warn on two overloads within the same class - it specifically warns on the case where a user might've mismatched what was intended to be an override but instead became an overload). At least that's my recollection.
[Bug libstdc++/101227] Clang++ fails to instantiate std::optional if nested type has a non-static data member initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101227 David Blaikie changed: What|Removed |Added CC||dblaikie at gmail dot com --- Comment #2 from David Blaikie --- My guess, libstdc++'s std::optional uses is_default_constructible unconditionally in some way, instantiating the template while the type parameter is incomplete (because the nested class is incomplete until the enclosing class is complete?). Essentially something like this: https://godbolt.org/z/6eohMofdb
[Bug c/82134] warn_unused_result triggers on empty structs even when they are used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82134 David Blaikie changed: What|Removed |Added CC||dblaikie at gmail dot com --- Comment #6 from David Blaikie --- For what it's worth, this is being actively worked around in gmock here: https://github.com/google/googletest/blob/662fe38e44900c007eccb65a5d2ea19df7bd520e/googlemock/include/gmock/gmock-more-actions.h#L295
[Bug c++/92413] [temp.explicit] Explicit template instantiations should not define member functions that are not defined at the point of instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92413
--- Comment #3 from David Blaikie ---
Ah, miswrote the example, here:
template struct C {void foo();};
template struct C;
template void C::foo() {
static_assert(sizeof(T) == 1);
}
Here's a godbolt comparing Clang trunk and GCC trunk:
https://godbolt.org/z/6jP_QM
[Bug c++/92413] [temp.explicit] Explicit template instantiations should not define member functions that are not defined at the point of instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92413
David Blaikie changed:
What|Removed |Added
CC||dblaikie at gmail dot com
--- Comment #1 from David Blaikie ---
>From the LLVM bug, I believe this code is valid C++ but GCC produces an error
for it:
template struct C {void foo();};
template struct C;
template void C::foo() {
static_assert(sizeof(int) == 1);
}
[Bug c++/48665] type of const member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48665 --- Comment #18 from David Blaikie --- Thanks - looks like this got hashed out on the C++ reflector in favor of this being invalid. The Clang bug has been re-opened to work on the fix there. Thanks! Sorry for the noise.
[Bug c++/48665] type of const member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48665 David Blaikie changed: What|Removed |Added CC||dblaikie at gmail dot com, ||richard-gccbugzilla@metafoo ||.co.uk --- Comment #15 from David Blaikie --- (jumping in here from https://bugs.llvm.org/show_bug.cgi?id=37846 ) Rejecting 'typeid(void() const)' seems like rejecting valid (if uncommon) code. Perhaps this should be fixed to accept the code, rather than reject it? "The compiler still reuses the same representation for const/volatile and for some attributes, sometimes misinterpreting one for the other." - sounds like rejecting this valid code is a workaround for that choice of representation?
[Bug c++/82724] Larger than needed DWARF type declarations for explicitly instantiated class templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82724 --- Comment #6 from David Blaikie --- (In reply to Paul Robinson from comment #5) > (In reply to David Blaikie from comment #4) > > What I'm saying is consumers already have to parse it to match up the same > > type name between compilers. > > Consumers of objects produced by gcc or unmodified clang do, yes. > Not that it's a good thing, it's just engineering reality. > > > Does the Sony debugger? > > The Sony debugger throws away the part and reconstructs info > to its liking from the template children. Good to understand > Given that the Sony debugger doesn't have to contend with gcc-produced > objects, and we have our own clang that does what we want, we're happy. > I'm just pointing out that gcc and upstream clang are doing something > that is reasonably viewed as non-conformant and consumer-unfriendly. > > It's the non-conformant part that mostly irks me. Aside from that, > as long as compilers and debuggers understand each other that's the > important thing. > > But you raised this bug really to point out an inconsistency within gcc > and that's worth addressing. Which way it goes is not a big deal for me. > You cc'd me on the bug, which I took as a chance to say my piece, and > thanks for the opportunity. *nod* Thanks for chiming in - didn't mean to be too offputting, seemed good to have all these views down here so GCC folks can consider them when figuring out what to do with this bug.
[Bug c++/82724] Larger than needed DWARF type declarations for explicitly instantiated class templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82724 --- Comment #4 from David Blaikie --- > Making consumers parse names on the off chance they contain semantically > significant information seems like a bit much, though. Especially if they > contain information in a ridiculous variety of spellings. Never mind things > like "Y" versus "(X)0u" you also have "const int" versus "int const" and all > the other very-large-number variations. What I'm saying is consumers already have to parse it to match up the same type name between compilers. Other than matching the names, what's the point of having the template parameters available? There's no syntactic way, as a user, to name those parameters to query them in GDB I've seen (the names of the parameters are available for expression evaluation in the context of the entity - if there's only a declaration of the entity, there's no such context). I don't think GDB is trying to understand the parameters, or provides any way for the user to interact with them in this case, but I could be wrong. Does the Sony debugger?
[Bug c++/82724] Larger than needed DWARF type declarations for explicitly instantiated class templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82724
--- Comment #2 from David Blaikie ---
Thanks for chiming in, Paul - figured it was an interesting case I ran into
that came up against/near some of the stuff we'd touched on recently (for a hot
second I thought maybe Clang's omission of the template parameters was actually
causing a problem - if GCC produced them & all, until I noticed that it only
produced them under this particular situation and not under the other similar
situation)
As for the function-without-parameters counterexample: That's a bit different
due to function overloading, and the parameter types not being in the name. So
a function without parameters would be ambiguous whereas a class template name
provides a unique name (& one the consumer already needs to parse to be able to
match up between two different compilers anyway - otherwise the consumer would
think GCC's type* ("foo<(X)0u>") and Clang's type ("foo") were different
types - even if it did check the template argument DIEs matched - the actual
name doesn't match. Arguably it'd be easier to match if the DIEs are present,
since a consumer could look for the < and strip everything after it to do the
name match, then do the parameter match separately)
Also, GCC doesn't produce template parameters if they aren't named:
template struct foo { };
foo f;
Contains no mention of the int type (except in the name of the structure type
"foo"). Arguably Clang could do that optimization too, but it does seem a
bit weird to me and probably not especially significant I'd guess.
* For the example:
enum X { Y };
template struct foo {};
foo f;
[Bug c++/82724] New: Larger than needed DWARF type declarations for explicitly instantiated class templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82724
Bug ID: 82724
Summary: Larger than needed DWARF type declarations for
explicitly instantiated class templates
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dblaikie at gmail dot com
Target Milestone: ---
When the vtable/key function debug info optimization kicks in, a declaration
(rather than a definition) of a type is produced:
$ cat foo.cpp
template struct foo {
T t;
virtual ~foo() {}
};
extern template struct foo;
foo *f;
$ g++-6.3 foo.cpp -g -c && llvm-dwarfdump-tot foo.o | grep
"DW_TAG\|DW_AT_name\|DW_AT_declaration"
...
DW_TAG_structure_type
DW_AT_name ("foo")
DW_AT_declaration (true)
DW_TAG_template_type_parameter
DW_AT_name("T")
...
But if the class template is only a declaration, then the DWARF is smaller -
the template_type_parameter is omitted (& thus anything that actual type
description and anything that type references is also omitted):
$ cat foo.cpp
template struct foo;
foo *f;
$ g++-6.3 foo.cpp -g -c && llvm-dwarfdump-tot foo.o | grep
"DW_TAG\|DW_AT_name\|DW_AT_declaration"
...
DW_TAG_structure_type
DW_AT_name ("foo")
DW_AT_declaration (true)
...
This seems more compact and GDB knows how to cope with it, since it's been this
way forever - so it probably makes sense to make the declaration in the first
case look like the declaration in the second case so it's more compact.
LLVM/Clang already does this.
[Bug debug/60833] Inheritance via typedef skips the typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60833 --- Comment #2 from David Blaikie --- ping
[Bug c++/60815] Inconsistent prologue line table location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60815 --- Comment #3 from David Blaikie --- ping
[Bug debug/60246] Emit debug info for explicit template instantiation definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60246 --- Comment #1 from David Blaikie --- ping
[Bug debug/78265] Excess emission of debug info for ODR used global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78265 --- Comment #3 from David Blaikie --- ping
[Bug debug/78322] Debug info still present for fully optimized away functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78322 --- Comment #3 from David Blaikie --- ping
[Bug debug/78321] Fission + type units + compression are suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78321 --- Comment #1 from David Blaikie --- ping
[Bug debug/78320] Excess debug info -fdebug-types-section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78320 --- Comment #1 from David Blaikie --- ping
[Bug debug/78322] Debug info still present for fully optimized away functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78322 --- Comment #2 from David Blaikie --- (In reply to Richard Biener from comment #1) > We produce an abstract copy for use by repeated inline copies. Yep! Is it still reasonable to consider it a bug (or at least a feature request) that this is still produced even when no inline copies are emitted?
[Bug debug/78322] New: Debug info still present for fully optimized away functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78322
Bug ID: 78322
Summary: Debug info still present for fully optimized away
functions
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dblaikie at gmail dot com
Target Milestone: ---
Consider this:
inline void __attribute__((always_inline)) f1() {
}
inline void __attribute__((always_inline)) f2() {
}
void f() {
f1();
}
GCC produces DWARF for f, and for f1 (where f1 has no high/low pc, no
inlined_subroutines referring to it, etc), but no DWARF for f2.
I think f1 and f2 should be the same - or perhaps a flag to allow them to be
treated the same.
If the function has been entirely optimized away, it's pretty close to not
having ever been called & producing DWARF for it doesn't seem to enhance the
user experience. (if it does, having DWARF for f2 would also enhance the user
experience in the same way) & the extra DWARF this produces (referenced types,
their types, etc) could be part of the reason Clang's DWARF is so much smaller
(1/6th of the type information - but due to several other bugs as well, which
I've filed).
[Bug debug/78321] New: Fission + type units + compression are suboptimal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78321 Bug ID: 78321 Summary: Fission + type units + compression are suboptimal Product: gcc Version: 6.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: dblaikie at gmail dot com Target Milestone: --- GCC is producing separate (though non-comdat) sections for each type in the .dwo file when using fission+type units. There's no need for these to be in separate sections - and it hurts compression greatly. (this may be one of the reasons Clang's .debug_types.dwo section is 1/6th the size of GCC's in a large example at Google) It may make merging types a little more efficient - by not having to decompress the whole set of types to merge in just one/a few types, so there's potentially a memory/storage tradeoff here.
[Bug debug/78320] New: Excess debug info -fdebug-types-section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78320
Bug ID: 78320
Summary: Excess debug info -fdebug-types-section
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dblaikie at gmail dot com
Target Milestone: ---
Enabling -fdebug-types-section causes nested type declarations and definitions
to be emitted by GCC, producing substantially more debug info than without this
option.
Consider:
struct a {
struct inner { };
} x;
struct b {
struct inner;
} y;
struct b::inner { };
struct c {
struct inner;
} z;
without -fdebug-types-section the DWARF contains 3 structures (a, b, c) and no
mention of nested types. With -fdebug-types-section the DWARF contains type
units for all 5 types. (& 'c's definition contains a declaration of 'inner',
where it did not in the baseline/no-type-units case)
At least it should be reasonable to argue that case (b) and (c) could/should be
treated similarly - if 'c' is valid DWARF, containing only the declaration of
inner, then the same representation should be used for 'b', since its inner
type is unused.
Beyond that, I'd argue 'a' could be represented this way too, even if it's not
precisely accurate to the source - it allows the DWARF to be smaller (& is
already what's done in the non-type-unit case).
And beyond /that/, I'd argue to be even closer to the original DWARF, and not
even emit the member type declarations: The set of members is unbounded and a
debugger/DWARF consumer is going to have to check all the definitions anyway
(check out how the DWARF looks for this:
struct foo {
template
void f() { }
};
... foo().f(); ...
- the type unit contains no mention of 'f' (which is right and proper, in my
opinion) - and the declaration that references the type unit, contains a
declaration of f)
Ultimately, I'd argue that member function templates, implicit special members,
and nested types all be treated in this way - omitted from the type unit, and
included only in the nested declaration. (FWIW, I'm partly arguing from this
perspective because it's how I implemented it in Clang and it seems
tidy/terse/simple to reason about, etc - but I can see some counter arguments)
Including types that are otherwise unreferenced can cause a substantial
increase in debug info (this bug, coupled with PR78265 may be part of the
reason that, for a large program at Google, GCC's (compressed) .debug_types
section in the object files is 500% larger than Clang's... - well, there's a
few other bugs I know of there too, to be fair)
[Bug debug/78265] Excess emission of debug info for ODR used global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78265
--- Comment #2 from David Blaikie ---
A side note/commentary:
Producing debug info for global variable declarations at all is an interesting
choice. If the whole program is built with debug info*, the global variable's
definition will have debug info and that should suffice, I think.
(* other optimizations in debug info that are the default for GCC make this
assumption (the vtable based class debug info optimization: struct foo {
virtual void f(); }; foo f; /* 'foo' emitted as a declaration here, a
definition wherever 'foo::f' is defined), so it would seem consistent to never
emit debug info for global variable declarations - with a flag to turn off this
assumption/optimization)
I mention this as it may make it easier to address this bug that way (though,
understandably, supporting the old behavior under a flag would be good and thus
this bug would still be an issue whenever that flag was used)
[Bug debug/78265] New: Excess emission of debug info for ODR used global variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78265
Bug ID: 78265
Summary: Excess emission of debug info for ODR used global
variables
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dblaikie at gmail dot com
Target Milestone: ---
ODR used global (& static class member) variables that are ODR used but never
actually referenced by live code still produce debug info. eg:
extern int i;
inline int f() {
return i;
}
Even though f is never called, 'i' still gets a debug info description.
If that's insufficiently compelling, consider this case (this turns up in
something like protobuf code repeatedly, as does the above example (look at how
protobufs emit default instances for the above example, the below example comes
up in some similar code I don't think I have a good public example of))
template
struct foo {
static const int i = -1;
int f() { return i; /* replace this with "return -1;" */ }
};
template
const int foo::i;
struct bar {
foo f;
int b() {
return f.f();
}
};
If you make the suggested substitution, no debug info is produced for this code
at all. As-is, it produces 110 byte CU (this is, of course, actually unbounded
& worse than 110 bytes in the real world case - because once you pull in the
variable, you pull in its type and then any types they need, etc).
[Bug debug/60833] New: Inheritance via typedef skips the typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60833
Bug ID: 60833
Summary: Inheritance via typedef skips the typedef
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dblaikie at gmail dot com
struct base {
};
typedef base tbase;
struct derived: tbase {
} x;
GCC doesn't emit the typedef of 'tbase' and instead describes 'derived' as
directly deriving from 'base'.
[Bug debug/60815] Inconsistent prologue line table location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60815
--- Comment #1 from David Blaikie ---
Oh - and if we can confirm the direction you're going with this (if the
decision is that the prologue should start, like Clang, at the opening '{'
always, for example) I'll go ahead and update the GDB test suite to either be
agnostic or to KFAIL those tests under GDB, referencing this bug.
[Bug debug/60815] New: Inconsistent prologue line table location
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60815
Bug ID: 60815
Summary: Inconsistent prologue line table location
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dblaikie at gmail dot com
CC: ccoutant at gcc dot gnu.org, echristo at gmail dot com
Host: x86_64
Target: x86_64
Given:
template
void func() // prologue
{
}
template void func();
void f2()
{ // prologue
}
struct foo {
void f3() // GCC prologue
{
}
void f4();
};
void (foo::*x)() = &foo::f3;
void foo::f4()
{ // prologue
}
GCC's line table shows the prologue of both of these functions as the line of
the function name, not the opening '{'. Yet if these functions are
non-templates or out-of-line, the prologue starts at the opening brace, not the
function name.
(backstory: Clang consistently uses the opening brace but fails some GDB tests
that rely on GCC's behavior, even though it's inconsistent (see
gdb.cp/cpexprs.exp for some examples). It'd be great if both GCC and Clang
could agree on this, one way or another, but if not, the GDB tests can of
course be made resilient to the difference by simply putting the '{' on the
same line as the function name)
[Bug libstdc++/60594] New: std::function of a type with a declared (but not defined) return type fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60594
Bug ID: 60594
Summary: std::function of a type with a declared (but not
defined) return type fails to compile
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: dblaikie at gmail dot com
CC: chandlerc at gmail dot com
#include
#include
struct bar;
#if BUG1
struct foo { std::function f; };
#elif BUG2
int i = std::is_copy_constructible>::value;
#else
std::function b;
#endif
struct bar { };
int main() {
std::function g([] { return bar(); });
}
Clang rejects both BUG1 and BUG2.
GCC ToT (20140219) rejects BUG2.
(I believe the Clang rejection of BUG1 is erroneous and will file a bug for
that)
libc++ with Clang compiles successfully in all 3 variants.
It looks like, somehow, instantiating the declaration of the std::function copy
constructor relies on the completeness of 'bar'.
[Bug debug/60246] New: Emit debug info for explicit template instantiation definitions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60246
Bug ID: 60246
Summary: Emit debug info for explicit template instantiation
definitions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: dblaikie at gmail dot com
CC: echristo at gmail dot com
A possible size optimization for debug info exists whenever an explicit
template instantiation declaration/definition is present.
If, in the translation unit that contains the explicit instantiation
definition, the full type is always emitted, then in the instantiation
declaration translation units the definition can be omitted in favor of just a
declaration.
I haven't done the analysis to see how valuable this is, but for simple things
like std::string it should fire and save a slew of debug info in consumers.
The problem is that this isn't backwards compatible (if the optimization is
done on the basis of declarations some debug info from (albeit
unnecessary/unuseful) explicit instantiations will be lost).
If the explicit instantiation declaration is actually useful (saves on code
emission in the declaration translation units and causes code to be emitted in
the defining translation unit) then this optimization is safe already - the
emission of the code for the member function will cause the type to be emitted
there.
But in the degenerate case such as:
template
struct foo {
// neither of these members would cause code to be emitted
int i;
void f1();
// void f2() {} // this would though
};
// template void foo::f1() { } // or this
template struct foo;
no functions are emitted (so the explicit instantiation decl/def was pointless,
but someone might write this) and thus the assumption fails and debug info is
broken (no translation unit ends up with the definition of 'foo').
The first step is to ensure that the definition is always emitted in a
translation unit with an explicit template instantiation definition. Then at
some point in the future its presence can be assumed and explicit instantiation
declarations can be optimized more aggressively.
[Bug debug/49366] pointer-to-member-function not given value in DW_TAG_template_value_param
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49366 David Blaikie changed: What|Removed |Added CC||dblaikie at gmail dot com --- Comment #1 from David Blaikie --- Any idea what value it should have? (how GDB would like to have the member function pointer encoded)
[Bug debug/55641] debug info for the type of a reference declared with a typedef has spurious 'const'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 --- Comment #4 from David Blaikie 2012-12-10 18:31:54 UTC --- (In reply to comment #3) > confirmed with various versions from 4.1 to 4.7 sorry, yes - I tested this with 4.7. Thanks for verifying the repro.
[Bug debug/55641] debug info for the type of a reference declared with a typedef has spurious 'const'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 --- Comment #1 from David Blaikie 2012-12-10 16:29:47 UTC --- Oh, and, tellingly, GCC (7.5) emits a DW_TAG_const_type in the DWARF data that Clang does not emit, which seems to be the relevant difference here.
[Bug debug/55641] New: debug info for the type of a reference declared with a typedef has spurious 'const'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 Bug #: 55641 Summary: debug info for the type of a reference declared with a typedef has spurious 'const' Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: dblai...@gmail.com Example code: typedef int &foo; int x; foo f(x); under gdb run "whatis f" and the answer is "const foo" when it should be plain "foo" (if you skip the typedef the answer is correctly "int&" not "int& const" or any similarly strange mismatch) Found in the GDB 7.5 test suite ( gdb.python/lib-types.exp ) - this is positively tested for, but so far as I can imagine that's by accident, not intent.
