[Bug debug/57519] New: DW_TAG_imported_declaration put in wrong class (base class instead of derived class)

Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: dje at google dot com Created attachment 30253 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30253action=edit assembler output [with svn head as of today] class

[Bug debug/61237] New: gcc puts line number 11 ahead of line number 10 in function call in debug info

: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: dje at google dot com I can imagine gcc's trying to be helpful here, but it's not working in this case (at least in IMHO). I want to set a breakpoint on line 10, but when I

[Bug target/30829] extra register zero extends

--- Comment #1 from dje at google dot com 2007-11-09 00:57 --- I looked into what's going on here. This is a problem in the i386.md lshr+zext combiner patterns (or a problem in the combine pass, depending on one's point of view). There are patterns in i386.md that are supposed

[Bug debug/45682] New: missing namespace parent die when using -gdwarf-4

using -gdwarf-4 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dje at google dot com GCC build triplet: amd64

[Bug debug/45997] New: __unknown__ type name for typedef'd int

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45997 Summary: __unknown__ type name for typedef'd int Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo:

[Bug libstdc++/65839] New: xmethods need updating once gdb decides how to fix 18285

Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: dje at google dot com https://sourceware.org/bugzilla/show_bug.cgi?id=18285 documents a mea culpa: ptype on an xmethod expression segvs gdb. Bleah. Once we decide how to handle this in gdb

[Bug debug/65838] New: DWARF type units should have DW_AT_comp_dir when needed

Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: dje at google dot com DWARF type units don't get DW_AT_comp_dir, and normally (for some definition of normally) they're not needed. But, for completeness sake, there are cases where

[Bug libstdc++/65840] New: type of result of at least some libstdc++ xmethods is different than real operator

Severity: minor Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: dje at google dot com Using libstdc++-v3/testsuite/libstdc++-xmethods/unique_ptr.cc as a testcase, and modifying it to ensure the * operator is compiled in: --- gcc

[Bug libstdc++/65839] xmethods need updating once gdb decides how to fix 18285

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65839 --- Comment #2 from Doug Evans dje at google dot com --- Re: changing xmethods. The thought was that they'd be changed in an upward compatible manner, but it's good to know we have a bit of freedom. Thanks!

[Bug libstdc++/65840] type of result of at least some libstdc++ xmethods is different than real operator

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65840 --- Comment #2 from Doug Evans dje at google dot com --- I think it should be more than just a matter of working in practice. A user may get confused by the difference in the type and wonder if time needs to be spent investigating the difference

[Bug libstdc++/65839] xmethods need updating once gdb decides how to fix 18285

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65839 --- Comment #3 from Doug Evans dje at google dot com --- [fyi] Here's the tentative patch for gdb. https://sourceware.org/ml/gdb-patches/2015-04/msg00947.html

[Bug c++/65669] New: Don't emit debug info for fake_ostream version of cerr (and others)

Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dje at google dot com While trying to debug a massive gdb performance issue with printing std::cerr I'm wasting time trying to create a good testcase. In one program std::cerr

[Bug c++/65669] Don't emit debug info for fake_ostream version of cerr (and others)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65669 --- Comment #2 from Doug Evans dje at google dot com --- I was wondering if one could just do a strip --strip-debug of globals_io.o in the Makefile.

[Bug libstdc++/65669] Don't emit debug info for fake_ostream version of cerr (and others)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65669 --- Comment #3 from Doug Evans dje at google dot com --- (In reply to Doug Evans from comment #2) I was wondering if one could just do a strip --strip-debug of globals_io.o in the Makefile. This doesn't work, as is, because gdb ignores the DIE

[Bug libstdc++/65839] xmethods need updating once gdb decides how to fix 18285

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65839 Doug Evans dje at google dot com changed: What|Removed |Added Status|NEW |RESOLVED

[Bug libstdc++/67440] pretty-printing of a const set fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67440 Doug Evans changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug libstdc++/67440] New: pretty-printing of a const set fails

++ Assignee: unassigned at gcc dot gnu.org Reporter: dje at google dot com Target Milestone: --- Type lookup in the pretty-printer of const set fails, set should be used instead. With the attached changes to the testcase, before the attached patch, one sees: Python Exception

[Bug libstdc++/67440] pretty-printing of a const set fails

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67440 --- Comment #1 from Doug Evans --- Created attachment 36288 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36288=edit patch + testcase This could use another set of eyes.