https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935
Tom Tromey changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95379
--- Comment #7 from Tom Tromey ---
(In reply to Asher Gordon from comment #6)
> (In reply to Tom Tromey from comment #5)
> > Since this warning is intended to work like sparse, introducing
> > a divergence here would seem to make the feature less
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509
Tom Tromey changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tromey at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509
--- Comment #3 from Tom Tromey ---
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/547388.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95509
Tom Tromey changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57612
--- Comment #4 from Tom Tromey ---
(In reply to H. Peter Anvin from comment #2)
> I would like to second this request, however, I would like to request that
> it issues a warning rather than an error. It can always be promoted to an
> error via
: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I'm using git master gcc from today.
I tried a simple coroutine program:
int func(int *x) {
for (int i = 0; i < 23; ++i)
co_yield x[i];
}
Compiling causes gcc to ICE:
murgatroyd. .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93458
Tom Tromey changed:
What|Removed |Added
Keywords||ice-on-invalid-code
--- Comment #1 from Tom
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
GCC accepts extended forms of constant expression.
An example that came up recently was:
const int a = 5;
const int b = a;
IIUC the standard permits the compiler to accept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93458
--- Comment #4 from Tom Tromey ---
> BTW, did you include ?
>
> (FAOD: it would still be broken if you did, but ISTM we might at some point
> add a hint that if the traits can't be found, you probably forgot that).
The code was exactly as writ
: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Consider this test case:
_Complex int x = 23i;
Compile with -g and examine the resulting DWARF:
<1><31>: Abbrev Number: 3 (DW_TAG_base_type)
<32>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93988
--- Comment #2 from Tom Tromey ---
(In reply to Richard Biener from comment #1)
> I wonder if there is (or should be) sth like DW_ATE_unsupported ... using
> DW_ATE_lo_user is indeed unfortunate but not wrong per-se. Adding
> a DW_ATE_GNU_comple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56376
Bug #: 56376
Summary: gdb needs a way to associate a vtable symbol with a
class type
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237
--- Comment #11 from Tom Tromey 2013-02-18 15:20:56
UTC ---
(In reply to comment #10)
> I don't think such an attribute belongs in the DWARF standard, since this is
> very much an internal detail of the ABI; another ABI might have just a s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56563
Bug #: 56563
Summary: no debuginfo for "explicit" operator
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56723
Bug #: 56723
Summary: wrong location in error message
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724
Bug #: 56724
Summary: sub-optimal location in error
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
Bug #: 56725
Summary: extra spaces in error message
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724
--- Comment #1 from Tom Tromey 2013-03-25 18:44:37
UTC ---
This affects g++ as well.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724
--- Comment #3 from Tom Tromey 2013-03-25 18:46:47
UTC ---
(In reply to comment #2)
> Though it does say the 3rd argument though.
Sure, it is just nicer if the compiler counts commas instead of me doing it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56740
Bug #: 56740
Summary: duplicat DW_TAG_const_type
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56974
Bug #: 56974
Summary: c++ ref qualifiers not represented in DWARF
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56989
Bug #: 56989
Summary: wrong location in error message
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57006
Bug #: 57006
Summary: extend DWARF to indicate types coming from template
parameters
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54205
Bug #: 54205
Summary: recursive .debug_macro inclusions
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13111
Tom Tromey changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54410
Bug #: 54410
Summary: doubled DW_TAG_template_type_param
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54979
Bug #: 54979
Summary: no warning for useless comparison
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55059
Bug #: 55059
Summary: DWARF missing concrete class definition
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50899
--- Comment #1 from Tom Tromey 2012-10-31 14:55:29
UTC ---
Author: tromey
Date: Wed Oct 31 14:55:20 2012
New Revision: 193036
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193036
Log:
PR other/50899
* doc/gcc.texi: Ad
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50899
Tom Tromey changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Created attachment 30161
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30161&action=edit
test case
I compiled the attached program with "g++ -g".
I used git g
: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
I built git master gcc today (317121db1372a50999ab1cba75aa59df0f2eff7c)
using the default arguments on my x86-64 Fedora 18 machine.
Then I compiled this program with the new g++ and ran it in gdb
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
It would sometimes be useful to be able to assert
that an expression does not have side effects.
For example, this would be very nice to have for
macros which
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
I'm using a recent (yesterda) gcc trunk from git.
I have no local patches applied.
I'm building a native gcc on x86-64 Fedora 18.
I configured with:
barimba. ./config.status --version
con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58476
--- Comment #2 from Tom Tromey ---
The problem occurs because I use --disable-static.
If I remove this, the bootstrap completes.
I am not sure whether or not this is a supported configuration.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50899
Bug #: 50899
Summary: need @direntry for gcov
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16063
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927
Bug #: 53927
Summary: wrong value for DW_AT_static_link
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237
--- Comment #8 from Tom Tromey 2012-07-12 18:34:08
UTC ---
I'd like to ping this again.
I've been working on adding support for new and delete to gdb.
The missing debuginfo here is a barrier to this.
I think gdb would generally like to call the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237
--- Comment #9 from Tom Tromey 2012-07-13 17:14:38
UTC ---
Likewise there isn't a super way to find out which
constructor is in-charge. The only way I could come up
with is to look at the linkage name; but this requires
excessive knowledge of th
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477
Tom Tromey changed:
What|Removed |Added
Target Milestone|--- |3.1.x/3.2.x
--- Comment #1 from Tom Tromey
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53006
--- Comment #2 from Tom Tromey 2012-04-16 18:01:17
UTC ---
(In reply to comment #0)
> match = self.compiled_rx.match(typename)
> print type(typename)
>
This is very odd. The code in context:
typename = self.get_basic_type(va
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
--- Comment #3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075
--- Comment #2 from Tom Tromey ---
(In reply to Jonathan Wakely from comment #1)
> Tom, do you know why this would be true on OS X?
Offhand I do not know. I think there are a few things that
could help us find out, though.
One would be to see t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237
--- Comment #13 from Tom Tromey ---
I was debugging this today:
https://sourceware.org/bugzilla/show_bug.cgi?id=15975
... and ran across this PR again.
GCC is still emitting a virtual destructor with no indication of
its vtable element location:
||tromey at gcc dot gnu.org
Resolution|--- |DUPLICATE
--- Comment #2 from Tom Tromey ---
Dup.
*** This bug has been marked as a duplicate of bug 58572 ***
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572
Tom Tromey changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
--- Comment #5 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572
Tom Tromey changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |tromey at gcc dot
gnu.org
: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Consider this program:
enum EE
{
ONE, TWO, THREE
};
int f (enum EE e)
{
int r = 0;
#pragma GCC diagnostic push
#pragma GCC diagnostic error "-Wswitch-enum"
switch (e)
{
: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
I couldn't find a way to make GCC emit DW_TAG_friend
or DW_AT_friend. A quick grep through dwarf2out.c
seems to confirm this.
I think these are needed for gdb to properly implement ADL,
tho
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49973
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51649
--- Comment #4 from Tom Tromey 2011-12-21 18:34:47
UTC ---
(In reply to comment #3)
> Tom, I assume the plan for the libstdc++ python printers is to have a
> python/libstdcxx/v7/printers.py for the libstdc++.so.7 library, right?
>
> As we have t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855
--- Comment #23 from Tom Tromey 2012-01-10 17:17:50
UTC ---
I thought I wrote a pass to do this optimization, but I can't find it now.
Anyway I think that would be the simplest approach by far.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21855
--- Comment #24 from Tom Tromey 2012-01-10 17:21:02
UTC ---
I found my code and it turns out I never finished it.
(I did write a java-specific devirtualization pass.)
Here is an introductory comment that explains my plans:
/* This pass implement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51649
--- Comment #7 from Tom Tromey 2012-01-19 21:59:07
UTC ---
Based on my first build of a --enable-symvers=gnu-versioned-namespace
compiler, I am thinking that just updating the regexps is ok.
There's no particular need to introduce the full v7 pyt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45690
--- Comment #7 from Tom Tromey 2012-01-20 14:59:51
UTC ---
gdb doesn't read .debug_pubtypes.
So the problem must be something else.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51649
Tom Tromey changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |tromey at redhat dot com
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51649
--- Comment #9 from Tom Tromey 2012-01-30 16:25:25
UTC ---
Author: tromey
Date: Mon Jan 30 16:25:11 2012
New Revision: 183732
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183732
Log:
PR libstdc++/51649:
* testsuite/libstdc++-pre
++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Consider this source:
int Foo;
struct Foo
{
int a;
};
extern int f(Foo x);
gcc (I'm using 8.2.1 from Fedora 28) says:
q.cc:8:14: warning: âfâ initialized and dec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
--- Comment #8 from Tom Tromey ---
Sorry about the extreme delay on this.
I think my patch has long since bit-rotted, but I can attach it for
reference. I believe my assignment situation got sorted out so this
should be fine to read and/or copy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
--- Comment #9 from Tom Tromey ---
Created attachment 45413
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45413&action=edit
ancient patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64862
--- Comment #10 from Tom Tromey ---
Also I think all the test suite changes never really worked.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80635
--- Comment #14 from Tom Tromey ---
(In reply to Jonathan Wakely from comment #8)
> Something like __builtin_unreachable() to say "trust me" would be nice, but
> I can't think how to do it.
How about an attribute that can be attached to the memb
onent: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Looking at the "dir" entry for the JIT, I see:
murgatroyd. grep jit install/share/info/dir
* libgccjit: (libgccjit.info). One line description of project.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91330
--- Comment #1 from Tom Tromey ---
This is pretty easy to fix in gcc/jit/docs/conf.py:
diff --git a/gcc/jit/docs/conf.py b/gcc/jit/docs/conf.py
index 3e630db47ef..1224bdcc07d 100644
--- a/gcc/jit/docs/conf.py
+++ b/gcc/jit/docs/conf.py
@@ -244,7
rmal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Consider this test case:
struct x
{
int a : 5;
int b : 2;
};
struct x x;
Compile with -g -c and then examine the DWARF.
For x::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61257
--- Comment #6 from Tom Tromey ---
(In reply to Eric Gallager from comment #4)
> (In reply to Sergei Trofimovich from comment #3)
> > (In reply to Sergei Trofimovich from comment #2)
> > > Having explicit flags like --enable-systemtap / --disable
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Joel Brobecker sent me an Ada test case so that I could see a real-life
example of the use of DW_TAG_variant_part (in support of some Rust
stuff I'm doing elsewhere).
For this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935
--- Comment #3 from Tom Tromey ---
(In reply to Pierre-Marie de Rodat from comment #2)
> Thinking more about it, the rule that the discriminant entry must be a child
> of the variant part entry sounds suspicious to me.
TBH this did not make sens
++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Apologies for the vagueness of this bug. I ran across a
pull request that mentions that gcc will sometimes emit an erroneous
'sr' mangling:
https://github.com/gimli-rs/cpp_dem
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I'm using the system gcc on Fedora 29:
gcc (GCC) 8.2.1 20180801 (Red Hat 8.2.1-2)
Consider this source:
struct s {
int f;
};
int x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935
--- Comment #10 from Tom Tromey ---
I have been looking at this again recently, for Ada, and now
I think perhaps the approach that GCC takes should be preferred.
At first I was thinking maybe the compiler could linearize
the members of the emitt
nent: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
This test case comes from this blog post:
https://nfrechette.github.io/2019/05/08/sign_flip_optimization/
(which also says that clang 8 performs this op
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
This test case comes from https://sourceware.org/bugzilla/show_bug.cgi?id=20020
Consider:
template
struct foo
{
static constexpr bool is_always_lock_free = true;
};
int
onent: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
gcc-jit has gcc_jit_context_new_rvalue_from_int and
gcc_jit_context_new_rvalue_from_long, but on some platforms
long might be 32 bits, but a program could still use int64_t
or lon
Assignee: dmalcolm at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Many functions in libgccjit.h take a pointer argument,
and it isn't clear which of these can be NULL and which cannot.
It would be a bit helpful if the nonnull attribute were ap
Assignee: dmalcolm at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
Currently all blocks must be terminated either with a jump or a return.
I think it should also be possible to terminate a block with
a call to a noreturn function. But, there is no way
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
The function gcc_jit_context_get_builtin_function is not documented.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87003
--- Comment #2 from Tom Tromey ---
I don't really know the best thing to do.
I see your point about graceful failure being a useful
feature, in cases where the result of some gcc-jit function
is passed as an argument to another one.
Maybe there
++
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Target Milestone: ---
I'm filing this on behalf of someone who posted this bug on reddit.
https://www.reddit.com/r/cpp/comments/99e1ri/interesting_gcc_optimizer_bug/
Copying text from there:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87062
--- Comment #1 from Tom Tromey ---
Analysis in the comments there puts the blame on -ftree-slp-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87104
--- Comment #13 from Tom Tromey ---
(In reply to pipcet from comment #12)
> So I think the performance difference is really significant for Emacs; my
> plan is to test all three versions on other programs, make sure the code
> works for C bitfie
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65158
Tom Tromey changed:
What|Removed |Added
Status|WAITING |REOPENED
--- Comment #2 from Tom Tromey --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935
--- Comment #7 from Tom Tromey ---
For Rust I ended up following the letter of the standard, so I'm going
to follow this in the gdb patches as well. That said, gdb can be adapted
to work with either approach, so it's not strictly necessary to ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83935
--- Comment #9 from Tom Tromey ---
(In reply to Pierre-Marie de Rodat from comment #8)
> Understood, thank you for the notice! As we have to tweak the spec one way
> or another for Ada, I suggest indeed we keep the way things are implemented
> in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #17 from Tom Tromey ---
The results in comment #13 seem to be missing some compilations --
I would have expected to see more files from libcpp in there.
As it is I only see directives.o and line-map.o.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041
--- Comment #12 from Tom Tromey 2012-11-16 20:46:33
UTC ---
(In reply to comment #11)
> Tom, do you have any idea what's going on in comment 6 and comment 8 of this
> bug?
Not offhand.
If you send me the failing executable(s) I can tak
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55482
Tom Tromey changed:
What|Removed |Added
CC||tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55059
--- Comment #3 from Tom Tromey 2013-01-03 19:29:28
UTC ---
(In reply to comment #2)
> So, where do we stand with this? Can GDB be changed to cope with this, or do
> you think it isn't valid DWARF?
It seems strange at least.
I don't ha
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55880
Bug #: 55880
Summary: demangler crash
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041
--- Comment #16 from Tom Tromey 2013-01-24 18:50:58
UTC ---
(In reply to comment #12)
> In my case the issue seems to be weird debuginfo emitted by gcc;
> look at what the breakpoint reports:
>
> Breakpoint 1, _GLOBAL__sub_I__Z4makem
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927
--- Comment #1 from Tom Tromey 2013-01-24 20:24:18
UTC ---
It seems that I read the wrong frame info in my original report.
However, the bug still exists. Here is a new and hopefully more
correct example showing the bug.
I used a relat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55059
--- Comment #5 from Tom Tromey 2013-01-28 20:08:11
UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > If we change gdb to cope with this, I think the effect will be to undo what
> > the patches here were attempting to accompl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927
--- Comment #4 from Tom Tromey 2013-01-31 19:40:16
UTC ---
(In reply to comment #3)
> I don't see the problem. On both i686 and x86_64 'p self_call' prints 1,
> which
> matches the value returned by the function, so debugging seems to be
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49090
--- Comment #3 from Tom Tromey 2013-01-31 20:11:36
UTC ---
(In reply to comment #2)
> Is GDB actually using the DW_TAG_template_*_param to generate the name of a
> type, or just using the pretty name generated by GCC for DW_AT_name?
>
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49090
--- Comment #5 from Tom Tromey 2013-01-31 20:25:54
UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > > Note that we don't currently generate those tags for uninstantiated types.
> > I don't think I understand this last comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49090
--- Comment #7 from Tom Tromey 2013-02-01 18:18:01
UTC ---
(In reply to comment #6)
> What do you think about G++ (also) switching to emitting K for DW_AT_name
> in this case? Would that break GDB type compatibility with other translation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927
--- Comment #8 from Tom Tromey 2013-02-01 18:22:21
UTC ---
> Yes, but you can do something useful even with this value of
> DW_AT_static_link, albeit not exactly what DWARF means.
Regardless, I think GCC should emit correct DWARF.
> I
1 - 100 of 311 matches
Mail list logo
