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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55482
Tom Tromey tromey at gcc dot gnu.org changed:
What|Removed |Added
CC||tromey
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
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 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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
: 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
: 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
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 tromey at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
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 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
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
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:
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
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 tromey at gcc dot gnu.org 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 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.
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:
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
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 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
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
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
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
: 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
config.status
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61803
Tom Tromey tromey at gcc dot gnu.org changed:
What|Removed |Added
Keywords||diagnostic
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
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. ***
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
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
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
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
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
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
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
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.
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
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
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
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.
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
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
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
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
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
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__
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
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
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
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
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
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
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
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
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
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
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
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
++
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
++
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
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
++
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
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
: 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
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
: 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
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.
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
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
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
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
: 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
: 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
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 - 100 of 309 matches
Mail list logo