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.
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_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99178
David Blaikie changed:
What|Removed |Added
CC||dblaikie at gmail dot com
--- Comment
++
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49130
David Blaikie changed:
What|Removed |Added
CC||dblaikie at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49312
David Blaikie changed:
What|Removed |Added
CC||dblaikie at gmail dot com
--- Comment
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, tho
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
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 ver
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 in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89549
David Blaikie changed:
What|Removed |Added
CC||dblaikie at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87729
David Blaikie changed:
What|Removed |Added
CC||dblaikie at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101227
David Blaikie changed:
What|Removed |Added
CC||dblaikie at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82134
David Blaikie changed:
What|Removed |Added
CC||dblaikie at gmail dot com
--- Comment
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92413
David Blaikie changed:
What|Removed |Added
CC||dblaikie at gmail dot com
--- Comment
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48665
David Blaikie changed:
What|Removed |Added
CC||dblaikie at gmail dot com
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.
>
> C
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 spellin
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 templ
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60833
--- Comment #2 from David Blaikie ---
ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60815
--- Comment #3 from David Blaikie ---
ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60246
--- Comment #1 from David Blaikie ---
ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78265
--- Comment #3 from David Blaikie ---
ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78322
--- Comment #3 from David Blaikie ---
ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78321
--- Comment #1 from David Blaikie ---
ping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78320
--- Comment #1 from David Blaikie ---
ping
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 sti
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
: 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 sec
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
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
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
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'.
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 sui
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
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49366
David Blaikie changed:
What|Removed |Added
CC||dblaikie at gmail dot com
--- Comment #1
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.
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.
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
45 matches
Mail list logo
