https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67440
Doug Evans changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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&action=edit
patch + testcase
This could use another set of eyes.
++
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65669
--- Comment #3 from Doug Evans ---
(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 with the real type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65839
Doug Evans changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65839
--- Comment #3 from Doug Evans ---
[fyi]
Here's the tentative patch for gdb.
https://sourceware.org/ml/gdb-patches/2015-04/msg00947.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65839
--- Comment #2 from Doug Evans ---
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!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65840
--- Comment #2 from Doug Evans ---
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. Tools shouldn't do t
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
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
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
wher
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65669
--- Comment #2 from Doug Evans ---
I was wondering if one could just do a strip --strip-debug of globals_io.o in
the Makefile.
ormal
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:
: 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,
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=30253&action=edit
assembler output
[with svn head as o
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: unassig.
>: Abbrev Number: 11 (DW_TAG_subprogram)
<58> DW_AT_specification: <0x3d>
<5c> DW_AT_decl_line : 13
<5d> DW_AT_low_pc : 0x0
<65> DW_AT_high_pc : 0xb
<6d> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa)
Notice that in t
--- 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 s
18 matches
Mail list logo
