https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837
--- Comment #4 from Tom Tromey ---
(In reply to Jakub Jelinek from comment #3)
> And perhaps we could also try to optimize the DW_FORM_sdata cases if there
> is no ambiguity (e.g. for 8-bit signed contexts with negative value
> DW_FORM_data1 co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837
--- Comment #1 from Tom Tromey ---
Also there was an old thread about this:
https://lists.dwarfstd.org/pipermail/dwarf-discuss/2010-July/000862.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118837
Bug ID: 118837
Summary: Interpretation of DW_FORM_data*
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118260
Bug ID: 118260
Summary: Automatically add some 'skip's from gdb helper code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54696
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #5 fr
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
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
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
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
--- Comm
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 f
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
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 a
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, tha
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
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 fro
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: f9ea41683444ebe11cfa45b052238997
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.
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.
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
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.
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++
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.
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 fr
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&action=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 y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91239
Tom Tromey changed:
What|Removed |Added
Status|WAITING |NEW
CC|
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 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65763
Tom Tromey changed:
What|Removed |Added
CC||townsend at astro dot wisc.edu
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64320
Tom Tromey changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63792
Tom Tromey changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65817
Tom Tromey changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
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. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96240
Tom Tromey changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRMED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66955
Tom Tromey changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96240
Tom Tromey changed:
What|Removed |Added
Resolution|DUPLICATE |---
Status|RESOLVED
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96240
Tom Tromey changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
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 fr
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.
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.
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 f
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.
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: preprocess
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
compi
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 fr
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: una
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 fr
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 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94669
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
Assigne
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
50 matches
Mail list logo
