[Bug libstdc++/55041] prettyprinting/shared_ptr cxx11 fails on some platforms

2012-11-16 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041 --- Comment #12 from Tom Tromey tromey at gcc dot gnu.org 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

[Bug fortran/55482] gfortran.dg/class_array_7.f03 execution failures with -fsanitize=address

2012-12-11 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55482 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey

[Bug debug/55059] [4.8 Regression] DWARF missing concrete class definition

2013-01-03 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55059 --- Comment #3 from Tom Tromey tromey at gcc dot gnu.org 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

[Bug other/55880] New: demangler crash

2013-01-04 Thread tromey at gcc dot gnu.org
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

[Bug libstdc++/55041] prettyprinting/shared_ptr cxx11 fails on some platforms

2013-01-24 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55041 --- Comment #16 from Tom Tromey tromey at gcc dot gnu.org 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

[Bug debug/53927] wrong value for DW_AT_static_link

2013-01-24 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927 --- Comment #1 from Tom Tromey tromey at gcc dot gnu.org 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

[Bug debug/55059] [4.8 Regression] DWARF missing concrete class definition

2013-01-28 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55059 --- Comment #5 from Tom Tromey tromey at gcc dot gnu.org 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

[Bug debug/53927] wrong value for DW_AT_static_link

2013-01-31 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927 --- Comment #4 from Tom Tromey tromey at gcc dot gnu.org 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

[Bug debug/49090] provide a way to recognize defaulted template parameters

2013-01-31 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49090 --- Comment #3 from Tom Tromey tromey at gcc dot gnu.org 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

[Bug debug/49090] provide a way to recognize defaulted template parameters

2013-01-31 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49090 --- Comment #5 from Tom Tromey tromey at gcc dot gnu.org 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

[Bug debug/49090] provide a way to recognize defaulted template parameters

2013-02-01 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49090 --- Comment #7 from Tom Tromey tromey at gcc dot gnu.org 2013-02-01 18:18:01 UTC --- (In reply to comment #6) What do you think about G++ (also) switching to emitting Kint for DW_AT_name in this case? Would that break GDB type

[Bug debug/53927] wrong value for DW_AT_static_link

2013-02-01 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53927 --- Comment #8 from Tom Tromey tromey at gcc dot gnu.org 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

[Bug debug/49090] provide a way to recognize defaulted template parameters

2013-02-01 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49090 --- Comment #10 from Tom Tromey tromey at gcc dot gnu.org 2013-02-01 21:44:15 UTC --- (In reply to comment #8) Does it make sense to you to use DW_AT_default_value as a flag here? That would be fine by me.

[Bug bootstrap/58572] [4.9 regression] make bootstrap-lean leads to installation failure (doing extra rebuilds and invoking system compiler)

2013-10-21 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot

[Bug libstdc++/59075] python pretty printer does not work at OS X

2013-11-11 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59075 --- Comment #2 from Tom Tromey tromey at gcc dot gnu.org --- (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

[Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location

2013-11-14 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237 --- Comment #13 from Tom Tromey tromey at gcc dot gnu.org --- 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

[Bug bootstrap/58666] make install after make bootstrap-lean fails starting with r202895

2013-11-15 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58666 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug bootstrap/58572] [4.9 regression] make bootstrap-lean leads to installation failure (doing extra rebuilds and invoking system compiler)

2013-11-15 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||krebbel at gcc dot

[Bug bootstrap/58572] [4.9 regression] make bootstrap-lean leads to installation failure (doing extra rebuilds and invoking system compiler)

2013-11-15 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58572 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tromey

[Bug c/59304] New: #pragma diagnostic pop fails with -Wswitch-enum

2013-11-26 Thread 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) { case ONE

[Bug debug/59319] New: gcc does not emit DW_AT_friend or DW_TAG_friend

2013-11-27 Thread tromey at gcc dot gnu.org
: 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, though I

[Bug debug/54205] New: recursive .debug_macro inclusions

2012-08-08 Thread tromey at gcc dot gnu.org
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

[Bug debug/13111] g++ debuginfo incorrect for verify.cc

2012-08-22 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13111 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED

[Bug debug/54410] New: doubled DW_TAG_template_type_param

2012-08-29 Thread tromey at gcc dot gnu.org
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

[Bug c/54979] New: no warning for useless comparison

2012-10-18 Thread tromey at gcc dot gnu.org
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

[Bug debug/55059] New: DWARF missing concrete class definition

2012-10-24 Thread tromey at gcc dot gnu.org
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

[Bug other/50899] need @direntry for gcov

2012-10-31 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50899 --- Comment #1 from Tom Tromey tromey at gcc dot gnu.org 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=gccview=revrev=193036 Log: PR other/50899

[Bug other/50899] need @direntry for gcov

2012-10-31 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50899 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug debug/56376] New: gdb needs a way to associate a vtable symbol with a class type

2013-02-18 Thread tromey at gcc dot gnu.org
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:

[Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location

2013-02-18 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237 --- Comment #11 from Tom Tromey tromey at gcc dot gnu.org 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

[Bug debug/56563] New: no debuginfo for explicit operator

2013-03-07 Thread tromey at gcc dot gnu.org
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

[Bug c++/56723] New: wrong location in error message

2013-03-25 Thread tromey at gcc dot gnu.org
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

[Bug c/56724] New: sub-optimal location in error

2013-03-25 Thread tromey at gcc dot gnu.org
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

[Bug c++/56725] New: extra spaces in error message

2013-03-25 Thread tromey at gcc dot gnu.org
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

[Bug c/56724] sub-optimal location in error

2013-03-25 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #1 from Tom Tromey tromey at gcc dot gnu.org 2013-03-25 18:44:37 UTC --- This affects g++ as well.

[Bug c/56724] sub-optimal location in error

2013-03-25 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56724 --- Comment #3 from Tom Tromey tromey at gcc dot gnu.org 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.

[Bug debug/56740] New: duplicat DW_TAG_const_type

2013-03-26 Thread tromey at gcc dot gnu.org
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:

[Bug debug/56974] New: c++ ref qualifiers not represented in DWARF

2013-04-15 Thread tromey at gcc dot gnu.org
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

[Bug c/56989] New: wrong location in error message

2013-04-17 Thread tromey at gcc dot gnu.org
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

[Bug debug/57006] New: extend DWARF to indicate types coming from template parameters

2013-04-19 Thread tromey at gcc dot gnu.org
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:

[Bug debug/16063] Debuggers need more information about enum types in C++

2012-06-29 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16063 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot

[Bug debug/53927] New: wrong value for DW_AT_static_link

2012-07-11 Thread tromey at gcc dot gnu.org
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

[Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location

2012-07-12 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237 --- Comment #8 from Tom Tromey tromey at gcc dot gnu.org 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

[Bug debug/37237] Debug information for virtual destructors omits DW_AT_vtable_elem_location

2012-07-13 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37237 --- Comment #9 from Tom Tromey tromey at gcc dot gnu.org 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

[Bug libstdc++/53477] pretty printer fails with: Python Exception type 'exceptions.IndexError' list index out of range

2012-07-13 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53477 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |3.1.x/3.2.x

[Bug debug/57369] New: type-less DW_TAG_const_type

2013-05-22 Thread tromey at gcc dot gnu.org
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=30161action=edit test case I compiled the attached program with g++ -g. I used git g++ from yesterday

[Bug debug/57487] New: vterminate.cc local variable optimized out

2013-05-31 Thread tromey at gcc dot gnu.org
: 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

[Bug c/57612] New: add builtin to assert that expression does not have side effects

2013-06-14 Thread tromey at gcc dot gnu.org
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

[Bug bootstrap/58476] New: bootstrap failure with Go enabled

2013-09-19 Thread tromey at gcc dot gnu.org
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 config.status

[Bug bootstrap/58476] bootstrap failure with Go enabled

2013-09-20 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58476 --- Comment #2 from Tom Tromey tromey at gcc dot gnu.org --- 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.

[Bug c/61803] New: error reports macro location first, but should not

2014-07-14 Thread tromey at gcc dot gnu.org
Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org This is not really a C-specific bug but I wasn't sure where else to file it. Consider this source: #define Nil ((int *) 0) double *fun(void) { return Nil; } Now compile: barimba. gcc

[Bug c++/61803] error reports macro location first, but should not

2014-07-15 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61803 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic

[Bug c++/61803] error reports macro location first, but should not

2014-07-15 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61803 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

2014-07-15 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 --- Comment #15 from Tom Tromey tromey at gcc dot gnu.org --- *** Bug 61803 has been marked as a duplicate of this bug. ***

[Bug c++/55252] Caret diagnostic doesn't show useful location when macro clashes with name in system header

2014-07-15 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55252 --- Comment #16 from Tom Tromey tromey at gcc dot gnu.org --- I've tripped across this enough that I've actually filed dups twice now. I think it would be best to change the ordering here. That is, the initial error ought to generally

[Bug debug/55641] debug info for the type of a reference declared with a typedef has spurious 'const'

2014-07-22 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot

[Bug c/59855] Support sparse-style __attribute__((designated_init)) on structures, requiring designated initializers

2014-07-30 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59855 --- Comment #3 from Tom Tromey tromey at gcc dot gnu.org --- Author: tromey Date: Wed Jul 30 15:02:59 2014 New Revision: 213293 URL: https://gcc.gnu.org/viewcvs?rev=213293root=gccview=rev Log: 2014-07-30 Tom Tromey tro...@redhat.com PR c

[Bug c/59855] Support sparse-style __attribute__((designated_init)) on structures, requiring designated initializers

2014-07-30 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59855 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

2014-07-30 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #33 from Tom Tromey tromey at gcc dot gnu.org --- My current patch fails on some of the sparse validation tests. E.g., attr-in-parameter.c: attr_in_parameter.c:8:4: warning: assignment from pointer to different address space

[Bug debug/55641] debug info for the type of a reference declared with a typedef has spurious 'const'

2014-08-06 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55641 --- Comment #9 from Tom Tromey tromey at gcc dot gnu.org --- I think this happens due to this code in gen_variable_die: tree type = TREE_TYPE (decl_or_origin); if (decl_by_reference_p (decl_or_origin)) add_type_attribute

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

2014-08-08 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Last

[Bug c/57612] add builtin to assert that expression does not have side effects

2014-08-08 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57612 --- Comment #1 from Tom Tromey tromey at gcc dot gnu.org --- You can see the thread here: http://patchwork.ozlabs.org/patch/343858/ My proposed patch didn't handle C++, which seems like something it probably should do.

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

2014-08-08 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #34 from Tom Tromey tromey at gcc dot gnu.org --- Created attachment 33277 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33277action=edit initial patch This is my current patch. I'm uploading it for safekeeping as I probably

[Bug libgcj/62068] libjava/prims.cc:807: possible missing call to va_end ?

2014-08-08 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62068 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot

[Bug libgcj/62068] libjava/prims.cc:807: possible missing call to va_end ?

2014-08-08 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62068 --- Comment #3 from Tom Tromey tromey at gcc dot gnu.org --- It was documented that way on some systems. Eg: http://www.cs.rit.edu/~hpb/Man/_Man_SunOS_4.1.3_html/html3/varargs.3.html Perhaps that isn't operative language any more; I guess I'm

[Bug libgcj/62068] libjava/prims.cc:807: possible missing call to va_end ?

2014-08-08 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62068 --- Comment #5 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Andreas Schwab from comment #4) varargs isn't stdargs. Doh. Thanks.

[Bug c/59855] Support sparse-style __attribute__((designated_init)) on structures, requiring designated initializers

2014-01-20 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59855 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot

[Bug c/59852] Support sparse-style __attribute__((bitwise)) (type attribute)

2014-01-20 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59852 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot

[Bug c/59852] Support sparse-style __attribute__((bitwise)) (type attribute)

2014-01-20 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59852 --- Comment #5 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Josh Triplett from comment #4) Also note that arithmetic operations between a bitwise and a known-zero value do not warn. I'm curious about this too. If it means

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

2014-01-31 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

2014-02-03 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #5 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Josh Triplett from comment #4) What version of sparse did you try that with? I can't seem to reproduce that with the current version, nor with older versions. The one

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

2014-02-05 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #6 from Tom Tromey tromey at gcc dot gnu.org --- Null pointer constants are treated specially, which makes sense, but only if they have type void * and are in address space 0. That is, this works: #define NULL ((__attribute__

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

2014-02-05 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #9 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Josh Triplett from comment #7) I can't think of a legitimate reason to have a null pointer constant in a non-zero address space; there's already a null pointer constant

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

2014-02-05 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #10 from Tom Tromey tromey at gcc dot gnu.org --- Relatedly, could you say what the option -Wcast-to-as provides beyond the normal warnings about changing address spaces? I wonder if this is something I should be pulling in as well

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

2014-02-05 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #14 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Josh Triplett from comment #11) Without -Wcast-to-as, you won't get a warning for unforced casts that add an address space. Thanks! Personally, I'd actually suggest

[Bug c/28901] -Wunused-variable ignores unused const initialised variables

2014-02-11 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28901 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot

[Bug c/13029] [3.4 Regression] static consts and -Wunused-variable

2014-02-17 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13029 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot

[Bug debug/32445] no debug information for loop counters

2014-02-18 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32445 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot

[Bug other/55880] demangler crash

2014-02-18 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55880 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

2014-02-20 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #17 from Tom Tromey tromey at gcc dot gnu.org --- It seems that force works on function parameters and casts but not direct assignments: bapiya. nl -ba /tmp/q.c 1#define A(N) __attribute__((address_space (N))) 2

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

2014-02-20 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #18 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Tom Tromey from comment #17) It seems that force works on function parameters and casts but not direct assignments: It's also an error in conditional expressions

[Bug c/59850] Support sparse-style pointer address spaces (type attributes)

2014-02-21 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59850 --- Comment #20 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Josh Triplett from comment #19) I brought this exact case up on linux-sparse, and Christopher Li's (quite reasonable) perspective was that it doesn't really make sense

[Bug debug/56974] c++ ref qualifiers not represented in DWARF

2014-03-06 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56974 --- Comment #2 from Tom Tromey tromey at gcc dot gnu.org --- (In reply to Jan Kratochvil from comment #1) : g++-4.8.2 for 'void f(int r) {}' produces DW_TAG_rvalue_reference_type. Or do you mean something else? ref qualifiers is a term from

[Bug debug/60603] New: .debug_macinfo has wrong line numbers for built-in macros

2014-03-20 Thread tromey at gcc dot gnu.org
Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org The DWARF standard says that macros coming from the command-line should have line number 0 in the .debug_macinfo data. I think this ought to apply to built-in macros

[Bug c++/60615] New: bad location in error from initializer

2014-03-21 Thread tromey at gcc dot gnu.org
++ Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Consider this source: struct v { int (*f1) (int); int (*f2) (); int (*f3) (int); int (*f4) (int); }; int func(int x) { return x; } int fv() { return 23; } struct v inst = { func, func, func

[Bug c++/60616] New: bad location from -Wunused-parameter

2014-03-21 Thread tromey at gcc dot gnu.org
++ Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Consider this source code: int whatever (int x, int y) { return x; } Compile it with g++: barimba. g++ -c -Wunused-parameter pr.cc pr.cc:1:5: warning: unused parameter ‘y’ [-Wunused-parameter

[Bug debug/60782] New: DWARF does not represent _Atomic

2014-04-07 Thread tromey at gcc dot gnu.org
Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org C11 has the _Atomic qualifier, but it isn't emitted in DWARF. I found this thread referencing the problem, but no corresponding GCC bug report: http://gcc.gnu.org/ml/gcc/2013-11/msg00139.html The DWARF bug

[Bug c++/60862] New: bad location in invalid conversion error

2014-04-16 Thread tromey at gcc dot gnu.org
++ Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org I'm using the Fedora 20 system gcc: barimba. gcc --version gcc (GCC) 4.8.2 20131212 (Red Hat 4.8.2-7) It seems unlikely to me that this bug is caused by Fedora changes. Consider this source: extern

[Bug c/60915] New: confusing diagnostic from attribute on function definition

2014-04-21 Thread tromey at gcc dot gnu.org
Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Consider this program: int something(void) __attribute__((__visibility__(default))) { return 23; } Compiling gives: barimba. gcc --syntax-only t.c t.c:2:1: error

[Bug c++/60916] New: truncated error message

2014-04-21 Thread tromey at gcc dot gnu.org
: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Compile this program: int f(char *); const char *get_something (); templatetypename T, int (*F) (const T *) int wrapper () { return F (get_something ()); } templatetypename T1, typename T2, int (*F) (const T1

[Bug c++/60917] New: sub-optimal diagnostic when instantiating template

2014-04-21 Thread tromey at gcc dot gnu.org
Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Consider this source code: typedef int callback (); int f(char *); const char *get_something (); templatetypename T, int (*F) (const T *) int wrapper () { return F (get_something

[Bug plugins/60954] New: gcc-plugin.h should set default visibility

2014-04-24 Thread tromey at gcc dot gnu.org
: plugins Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org gcc-plugin.h declares two symbols that must be exported by the plugin: plugin_is_GPL_compatible and plugin_init. I think it would be nice for plugin authors if these two declarations had

[Bug c/60988] New: transparent_union doesn't appear in the gcc manual index

2014-04-28 Thread tromey at gcc dot gnu.org
Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org I expected to find some mention of transparent_union in the index, but did not. See info gcc, then i transparent_union RET.

[Bug debug/41736] missing DW_TAG_template_*_ in some cases

2014-04-29 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41736 --- Comment #10 from Tom Tromey tromey at gcc dot gnu.org --- Today I noticed another case. If you have a template like: templatetypename R, const char *NAME, typename A [...] ... then NAME is not given a value in the instantiation: 265c5

[Bug debug/49312] Make DW_AT_name contain only simple name, no template-id

2014-04-29 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49312 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot

[Bug debug/61014] [4.7/4.8/4.9/4.10 Regression] gdb can't find symbol of derived data type array in nested subroutine

2014-05-07 Thread tromey at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot

[Bug debug/61116] New: redundant DWARF with VLAs

2014-05-08 Thread tromey at gcc dot gnu.org
Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Compile this program with -g -O2: void f(int n) { struct s { int vla[n]; } sv; union u { int vla[n]; } uv; } Now examine the resulting DWARF. I see redundant definitions of the array type: 1a2: Abbrev Number

[Bug debug/61132] New: bad DWARF for VLA in the middle of a struct

2014-05-09 Thread tromey at gcc dot gnu.org
: debug Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Consider this source: void f(int n) { struct s { int before; int vla[n]; int after; } sv; } This uses the GNU extension of a VLA in the middle of a structure. The DWARF generated for this is odd

[Bug c/61162] New: possibly bad error location with -Wc++-compat

2014-05-12 Thread tromey at gcc dot gnu.org
: c Assignee: unassigned at gcc dot gnu.org Reporter: tromey at gcc dot gnu.org Consider this source: enum e { ZERO = 0, ONE }; enum e e_val; void f(void) { e_val = 0; } Compile with -Wc++-compat: bapiya. gcc -Wc++-compat --syntax-only r.c r.c: In function ‘f’: r.c:7:3

[Bug c/61162] possibly bad error location with -Wc++-compat

2014-05-12 Thread tromey at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 --- Comment #2 from Tom Tromey tromey at gcc dot gnu.org --- Note that it is also wrong for a conversion diagnosed in a return: enum e { ZERO = 0, ONE }; enum e f(void) { return 0; } barimba. gcc --syntax-only -Wc++-compat r.c r.c

  1   2   3   4   >