[Bug middle-end/32667] builtin operator= generates memcpy with overlapping memory regions
--- Comment #5 from ppluzhnikov at google dot com 2009-05-06 16:36 --- (In reply to comment #3) > Note that this is likely not a problem in practice as > memcpy (p, p, sizeof (*p)) is difficult to implement > in a way that would make it not work. >From Julian Seward: JS> AIUI, POSIX says the src==dst case is not allowed (along with all other JS> overlapping cases) because (eg) on PowerPC, it is possible to make a high JS> performance memcpy that preallocates the destination area in D1 using JS> dcbz instructions, which create the line in D1 and fill it full of JS> zeroes. This avoids dragging the destination line up the memory JS> hierarchy only to completely overwrite it with stuff from the source. JS> JS> Result is however that if the src and dst overlap, in any way, including JS> completely, then this causes zeroes to be written into the src area (!) JS> which is certainly not what you want. This bug is likely fixed by: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00932.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32667
[Bug debug/40012] [4.5 Regression] Revision 146817 generated bad debug info for local variables
--- Comment #6 from ppluzhnikov at google dot com 2009-06-02 23:02 --- Also a problem on x86_64-linux: http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00190.html -- ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug debug/40012] [4.5 Regression] Revision 146817 generated bad debug info for local variables
--- Comment #12 from ppluzhnikov at google dot com 2009-06-27 00:49 ---
This appears to still be broken in 32-bit mode.
I just built GCC @148996 on x86_64, and compiled the attached test case with
'-m32':
(gdb) start
Breakpoint 1 at 0x80483d9: file gcc-pr40012-test.c, line 24.
main () at gcc-pr40012-test.c:24
24list a3 = { 0 };
(gdb) n
25f0(0, 0, 0, &a3);
(gdb) p &a3
$1 = (list *) 0xccb4
(gdb) s
f0 (a=0x0, b=0x0, c=0x0, d=0xcc8c) at gcc-pr40012-test.c:15
15 for(problem = d; problem; problem = problem->next) {
Clearly GDB and GCC are in disagreement about the location of a3.
Disassebly shows:
0x080483d0 :push %ebp
0x080483d1 :mov%esp,%ebp
0x080483d3 :and$0xfff0,%esp
0x080483d6 :sub$0x20,%esp
0x080483d9 :movl $0x0,0x1c(%esp)
0x080483e1 : lea0x1c(%esp),%eax
0x080483e5 : mov%eax,0xc(%esp)
0x080483e9 : movl $0x0,0x8(%esp)
0x080483f1 : movl $0x0,0x4(%esp)
0x080483f9 : movl $0x0,(%esp)
0x08048400 : call 0x8048394
0x08048405 : mov$0x0,%eax
0x0804840a : leave
0x0804840b : ret
readelf -w:
<1><1ee>: Abbrev Number: 12 (DW_TAG_subprogram)
<1ef> DW_AT_external: 1
<1f0> DW_AT_name: (indirect string, offset: 0xf5): main
<1f4> DW_AT_decl_file : 1
<1f5> DW_AT_decl_line : 22
<1f6> DW_AT_type: <0x1df>
<1fa> DW_AT_low_pc : 0x80483d0
<1fe> DW_AT_high_pc : 0x804840c
<202> DW_AT_frame_base : 0x38(location list)
<206> DW_AT_sibling : <0x218>
<2><20a>: Abbrev Number: 13 (DW_TAG_variable)
<20b> DW_AT_name: a3
<20e> DW_AT_decl_file : 1
<20f> DW_AT_decl_line : 24
<210> DW_AT_type: <0x161>
<214> DW_AT_location: 2 byte block: 91 14 (DW_OP_fbreg: 20)
And
0038 080483d0 080483d1 (DW_OP_breg4: 4)
0038 080483d1 080483d3 (DW_OP_breg4: 8)
0038 080483d3 0804840b (DW_OP_breg5: 8)
0038 0804840b 0804840c (DW_OP_breg4: 4)
0038
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug debug/40012] [4.5 Regression] Revision 146817 generated bad debug info for local variables
--- Comment #14 from ppluzhnikov at google dot com 2009-06-29 20:11 --- I verified that @146817 is not causing the current 32-bit breakage; I'll open a separate PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug debug/40596] New: [4.5 regression] Bad debug info for local variables on i386.
The test case from bug 40012 still fails in current mainline @149059 in 32-bit
mode:
--- cut ---
struct list_s {
struct list_s* next;
};
typedef struct list_s list;
void f1(void*, list*);
int
f0(void* a,
void* b,
void* c,
list* d)
{
list* problem;
for(problem = d; problem; problem = problem->next) {
int variable = 0;
f1(c, problem);
}
return (0);
}
int main()
{
list a3 = { 0 };
f0(0, 0, 0, &a3);
return 0;
}
void f1(void*a, list*b) { }
--- cut ---
gcc-svn-install-149059/bin/gcc -g gcc-pr40012-test.c -m32
gdb -q a.out
(gdb) b main
Breakpoint 1 at 0x80483d9: file gcc-pr40012-test.c, line 24.
(gdb) r
Breakpoint 1, main () at gcc-pr40012-test.c:24
24list a3 = { 0 };
(gdb) n
25f0(0, 0, 0, &a3);
(gdb) p &a3
$1 = (list *) 0xccb4
(gdb) s
f0 (a=0x0, b=0x0, c=0x0, d=0xcc8c) at gcc-pr40012-test.c:15
15 for(problem = d; problem; problem = problem->next) {
Note mismatch between where GDB thinks &a3 is and the actual address.
[AFAICT, this is currently causing 300+ failures in the GDB test suite.]
--
Summary: [4.5 regression] Bad debug info for local variables on
i386.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppluzhnikov at google dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40596
[Bug debug/40596] [4.5 regression] Bad debug info for local variables on i386.
--- Comment #3 from ppluzhnikov at google dot com 2009-06-29 22:36 --- Confirmed working correctly @147994. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40596
[Bug debug/40596] [4.5 regression] Bad debug info for local variables on i386.
--- Comment #8 from ppluzhnikov at google dot com 2009-07-29 22:51 --- Confirm: r149235 fixes the problem here :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40596
[Bug c/40909] New: GCC mis-optimizes GDB
= 0x7ff7fc35af9, st_mtime = 0x0, st_ctime = 0x1}
In the non-optimized case, immediately after _stat returns:
(gdb) p/x st
$1 = {st_dev = 0x2, st_ino = 0x0, st_mode = 0x81ff, st_nlink = 0x1,
st_uid = 0x0, st_gid = 0x0, st_rdev = 0x2, st_size = 0x12c9aa9,
st_atime = 0x4a713f85, st_mtime = 0x4a713f85, st_ctime = 0x4a713f83}
--- reproduces with t.c ---
#include
#include
#include
int main(int argc, char *argv[])
{
struct stat st;
if (0 == stat(argv[0], &st))
printf("mode = %x\n", st.st_mode);
return 0;
}
--- t.c ---
/usr/local/mingw-w64/bin/x86_64-w64-mingw32-gcc -g t.c -O2 && ./a.exe
mode = 0
/usr/local/mingw-w64/bin/x86_64-w64-mingw32-gcc -g t.c -O0 && ./a.exe
mode = 81ff
--
Summary: GCC mis-optimizes GDB
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppluzhnikov at google dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: x86_64-w64-mingw32
GCC target triplet: x86_64-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
[Bug c/40909] GCC mis-optimizes GDB
--- Comment #4 from ppluzhnikov at google dot com 2009-07-30 14:03 --- Created an attachment (id=18272) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18272&action=view) pre-processed t.c Some answers: The -fno-strict-aliasing does help: /usr/local/mingw-w64/bin/x86_64-w64-mingw32-gcc -g t.c -O2 -fno-strict-aliasing && ./a.exe mode = 81ff > which revision of mingw-w64-crt and mingw-w64-headers the reporter used For the record, I am just following up on GDB bug report from here: http://sourceware.org/ml/gdb-patches/2009-07/msg00634.html I did not build mingw-w64 myself, but used a snapshot build from here: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-cygwin-1.5.25-15_20090726.tar.bz2/download -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
[Bug c/40909] stat produces incorrect result with w64-mingw under -O2
--- Comment #10 from ppluzhnikov at google dot com 2009-07-31 15:56 --- Filed MingW bug here: https://sourceforge.net/tracker/?func=detail&aid=2830386&group_id=2435&atid=102435 -- ppluzhnikov at google dot com changed: What|Removed |Added Summary|GCC mis-optimizes GDB |stat produces incorrect ||result with w64-mingw under ||-O2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
[Bug c++/39285] New: Missing debug info for enum members in C++
GCC @144404 does not generate DW_AT_const_value for enum members in C++ mode
(in C everything appears fine). This is a regression from 4.3.1.
Test case:
enum E { red = 1, green = 42 };
int main()
{
E e = red;
return e;
}
When above is compiled with gcc-4.3.1, readelf -w shows:
<2><2f>: Abbrev Number: 3 (DW_TAG_enumerator)
<30> DW_AT_name: red
<34> DW_AT_const_value : 1
<2><35>: Abbrev Number: 4 (DW_TAG_enumerator)
<36> DW_AT_name: (indirect string, offset: 0x8): green
<3a> DW_AT_const_value : 42
<1><3c>: Abbrev Number: 5 (DW_TAG_subprogram)
...
When compiled with gcc-4.4.0:
<2><2f>: Abbrev Number: 3 (DW_TAG_enumerator)
<30> DW_AT_name: red
<2><34>: Abbrev Number: 4 (DW_TAG_enumerator)
<35> DW_AT_name: (indirect string, offset: 0x8): green
<1><3a>: Abbrev Number: 5 (DW_TAG_subprogram)
...
AFAICT, this is causing the following GDB tests to fail:
FAIL: gdb.cp/classes.exp: print obj_with_enum (2)
FAIL: gdb.cp/classes.exp: print obj_with_enum.priv_enum
FAIL: gdb.cp/classes.exp: ptype obj_with_enum.priv_enum
FAIL: gdb.cp/classes.exp: print ('ClassWithEnum::PrivEnum') 42
FAIL: gdb.cp/m-data.exp: simple object, enum
FAIL: gdb.cp/m-data.exp: derived template object, derived enum
FAIL: gdb.cp/m-data.exp: template object, derived enum
FAIL: gdb.cp/m-static.exp: derived template object, static enum
FAIL: gdb.cp/m-static.exp: template object, static derived enum
--
Summary: Missing debug info for enum members in C++
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppluzhnikov at google dot com
GCC build triplet: i686-host_pc-linux-gnu
GCC host triplet: i686-host_pc-linux-gnu
GCC target triplet: i686-host_pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39285
[Bug c/39306] New: -fstack-check + large frame == SIGSEGV
Discovered as a failure of GDB test:
FAIL: gdb.base/stack-checking.exp: continue to breakpoint: breakpoint for big
frame
With current SVN head @144426:
/* t.c */
void foo() { char buf[524188]; }
int main() { foo(); return 0; }
i686-unknown-linux-gnu-gcc t.c -fstack-check && ./a.out
Segmentation fault
AFAICT, this is a regression from 4.3.1
Problem also happens in x86_64-unknown-linux-gnu.
Minimal size to crash appears to be about 57058.
--
Summary: -fstack-check + large frame == SIGSEGV
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ppluzhnikov at google dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39306
[Bug target/18749] GCC fails to mark stack-popping instruction in unwind-info
--- Comment #5 from ppluzhnikov at google dot com 2009-03-27 01:51 --- dup of bug 12990 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18749
[Bug c++/56235] New: [4.8 regression] Bogus "error: invalid conversion from ‘unsigned char’ to ‘B::Mode’ [-fpermissive]"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56235
Bug #: 56235
Summary: [4.8 regression] Bogus "error: invalid conversion from
‘unsigned char’ to ‘B::Mode’ [-fpermissive]"
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Test case:
struct A
{
A (const A &);
};
struct B
{
A a;
enum Mode { };
Mode m:8;
};
struct C
{
C();
B b;
};
C fn()
{
return C();
}
The test compiles fine with 4.7, fails with 4.8 (20130205 (experimental)) but
only in C++11 mode:
g++ -c -std=c++11 t.ii
t.ii: In constructor ‘B::B(B&&)’:
t.ii:6:8: error: invalid conversion from ‘unsigned char’ to ‘B::Mode’
[-fpermissive]
struct B
^
t.ii: In constructor ‘C::C(C&&)’:
t.ii:13:8: note: synthesized method ‘B::B(B&&)’ first required here
struct C
^
t.ii: In function ‘C fn()’:
t.ii:21:14: note: synthesized method ‘C::C(C&&)’ first required here
return C();
^
Google ref: b/8152830
[Bug c++/56237] New: [4.8 regression] ICE in lang_* check: failed in push_local_name, at cp/decl.c:924
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56237
Bug #: 56237
Summary: [4.8 regression] ICE in lang_* check: failed in
push_local_name, at cp/decl.c:924
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Test case reduced from jscoverage/jscpucfg.cpp
int main () {
static union { } u;
{ static union { } u; }
}
Compiles fine with 4.7. Fails with g++ (GCC) 4.8.0 20130205 (experimental) in
C++11 mode:
g++ -c t.cc # ok
g++ -c -std=c++11 t.ii
t.ii: In function ‘int main()’:
t.ii:3:22: internal compiler error: lang_* check: failed in push_local_name, at
cp/decl.c:924
{ static union { } u; }
^
0x697eb3 lang_check_failed(char const*, int, char const*)
../../gcc/cp/tree.c:3946
0x53e29b push_local_name
../../gcc/cp/decl.c:924
0x53e29b cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:6286
...
[Bug c++/56237] [4.8 regression] ICE in lang_* check: failed in push_local_name, at cp/decl.c:924
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56237 Paul Pluzhnikov changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #1 from Paul Pluzhnikov 2013-02-07 05:49:29 UTC --- Google ref: b/8152937
[Bug c++/56238] New: [4.8 regression] ICE in tree check: expected record_type or union_type or qual_union_type, have template_type_parm in lookup_conversions, at cp/search.c:2515
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56238
Bug #: 56238
Summary: [4.8 regression] ICE in tree check: expected
record_type or union_type or qual_union_type, have
template_type_parm in lookup_conversions, at
cp/search.c:2515
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Test case:
class A
{
template < typename T > T& get ();
template < typename T > class B
{
void RemovePoint (A& value)
{
static_cast < double >(value.get < T > ());
}
};
};
Compiles fine with 4.7.x, with 4.8 without -std=c++11.
ICE's with -std=c++11 using
g++ (GCC) 4.8.0 20130205 (experimental)
g++ -c t.ii -std=c++11
t.ii: In member function ‘void A::B::RemovePoint(A&)’:
t.ii:8:55: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have template_type_parm in lookup_conversions,
at cp/search.c:2515
static_cast < double >(value.get < T > ());
^
0xc6159a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:8946
0x66c962 tree_check3
../../gcc/tree.h:3709
...
Google ref: b/8153313
[Bug c++/56241] New: ICE in toplev.c:332 on invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56241
Bug #: 56241
Summary: ICE in toplev.c:332 on invalid
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
This is a result of test reduction gone bad. The test is invalid, but shouldn't
crash the compiler.
struct pair {
constexpr pair (const) :
};
template < 0 >
make_pair () {
}
pair prefix[] = { 0, make_pair }
Using g++ (GCC) 4.8.0 20130205 (experimental):
g++ -c -std=c++11 t.ii
t.ii:2:19: error: ISO C++ forbids declaration of ‘parameter’ with no type
[-fpermissive]
constexpr pair (const) :
^
t.ii: In constructor ‘constexpr pair::pair(int)’:
t.ii:2:26: error: expected identifier at end of input
constexpr pair (const) :
^
t.ii:2:26: error: expected ‘{’ at end of input
t.ii: At global scope:
t.ii:4:12: error: expected identifier before numeric constant
template < 0 >
^
t.ii:4:12: error: expected ‘>’ before numeric constant
t.ii:5:12: error: ISO C++ forbids declaration of ‘make_pair’ with no type
[-fpermissive]
make_pair () {
^
t.ii:7:32: error: conversion from ‘’ to
non-scalar type ‘pair’ requested
pair prefix[] = { 0, make_pair }
^
t.ii:7:32: internal compiler error: Segmentation fault
0xa7fd6f crash_signal
../../gcc/toplev.c:332
0xc69563 non_type_check
../../gcc/tree.h:3847
0xc69563 build_constructor(tree_node*, vec*)
../../gcc/tree.c:1422
...
[Bug c++/56243] New: [4.8 regression] ICE in tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6645
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56243
Bug #: 56243
Summary: [4.8 regression] ICE in tree check: expected
field_decl, have identifier_node in
fixed_type_or_null, at cp/class.c:6645
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Google ref b/8153611
Looks very similar to PR53816.
Test:
class A
{
virtual int String ();
};
class F: public A { };
template < typename V > class G
{
V value;
};
class D
{
template < int N > void Verify(const int (&p1)[N]) const {
for (int iter; G < A > *x = 0;)
{
F& name = x->value;
name.String ();
}
}
};
ICE with g++ (GCC) 4.8.0 20130205 (experimental).
g++ -c t.ii # ok
g++ -c -std=c++11 t.ii
t.ii: In member function ‘void D::Verify(const int (&)[N]) const’:
t.ii:19:22: internal compiler error: tree check: expected field_decl, have
identifier_node in fixed_type_or_null, at cp/class.c:6645
name.String ();
^
0xc6159a tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:8946
0x5cd853 tree_check
../../gcc/tree.h:3669
...
[Bug c/56246] New: [4.8 regression] ICE in assign_by_spills, at lra-assigns.c:1262
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56246
Bug #: 56246
Summary: [4.8 regression] ICE in assign_by_spills, at
lra-assigns.c:1262
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Test case:
void NoBarrier_AtomicExchange (long long *ptr) {
while (__sync_val_compare_and_swap (ptr, 1, 0) );
}
Using g++ (GCC) 4.8.0 20130205 (experimental):
g++ -c -m32 -O2 -fPIC -fno-omit-frame-pointer test.ii
test.ii: In function 'void NoBarrier_AtomicExchange(long long int*)':
test.ii:3:1: internal compiler error: in assign_by_spills, at
lra-assigns.c:1262
}
^
0x995de3 assign_by_spills
../../gcc/lra-assigns.c:1262
0x996a93 lra_assign()
../../gcc/lra-assigns.c:1419
0x992d11 lra(_IO_FILE*)
../../gcc/lra.c:2308
0x95ae78 do_reload
../../gcc/ira.c:4623
0x95ae78 rest_of_handle_reload
../../gcc/ira.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Same crash after update to r195864.
[Bug c++/56262] New: [4.8 regression] ICE in ipa_make_edge_direct_to_target, at ipa-prop.c:2111
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56262 Bug #: 56262 Summary: [4.8 regression] ICE in ipa_make_edge_direct_to_target, at ipa-prop.c:2111 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ppluzhni...@google.com Google ref: b/8152835 Very similar to PR 55264, but reproduces @r195889 g++ -w -c -O2 -std=c++11 --param=large-stack-frame=16000 -fno-strict-aliasing -fno-exceptions test.ii test.ii:1148:2: internal compiler error: in ipa_make_edge_direct_to_target, at ipa-prop.c:2111 } ^ 0x94bb9e ipa_make_edge_direct_to_target(cgraph_edge*, tree_node*) ../../gcc/ipa-prop.c:2111 0x94bd8e try_make_edge_direct_simple_call ../../gcc/ipa-prop.c:2182 0x94bd8e update_indirect_edges_after_inlining ../../gcc/ipa-prop.c:2274 0x94bd8e propagate_info_to_inlined_callees ../../gcc/ipa-prop.c:2333 0x94c1c3 ipa_propagate_indirect_call_infos(cgraph_edge*, vec*) ../../gcc/ipa-prop.c:2363 0xec5034 inline_call(cgraph_edge*, bool, vec*, int*, bool) ../../gcc/ipa-inline-transform.c:255 0xec3bdd ipa_inline ../../gcc/ipa-inline.c:1850 Please submit a full bug report, Unfortunately, I've been running creduce for several days, and I still have 40K+ test case that I can't seem to reduce: deleting anything from it causes the bug to hide. I am hoping above line numbers may be sufficient.
[Bug c++/56272] New: Poor diagnostics for error: specialization of ... after instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56272
Bug #: 56272
Summary: Poor diagnostics for error: specialization of ...
after instantiation
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Test case:
template class A
{
void Invert ()
{
A < double >a;
}
};
template class A;
template <> void A < double >::Invert ();
g++ -c t.ii
t.ii:11:40: error: specialization of ‘void A::Invert() [with T = double]’
after instantiation
Yes, but where was instantiation triggered?
In this reduced test case, it's obvious, but in a real test case I have 2MB of
text, the code builds fine with gcc-4.7, and the instantiation point is nowhere
to be seen.
[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265 Paul Pluzhnikov changed: What|Removed |Added CC||ppluzhnikov at google dot ||com --- Comment #1 from Paul Pluzhnikov 2013-02-10 18:45:31 UTC --- *** Bug 56262 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/56262] [4.8 regression] ICE in ipa_make_edge_direct_to_target, at ipa-prop.c:2111
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56262 Paul Pluzhnikov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Paul Pluzhnikov 2013-02-10 18:45:31 UTC --- (In reply to comment #1) > Perhaps dup of PR56265 ? The stack trace I get on the test from PR56265 is identical to what I have here. Let's hope this is exact dup. *** This bug has been marked as a duplicate of bug 56265 ***
[Bug tree-optimization/56265] [4.8 Regression] ICE in ipa_make_edge_direct_to_target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56265 --- Comment #3 from Paul Pluzhnikov 2013-02-12 00:48:01 UTC --- Thanks for the fix. We've confirmed that this fix also fixes the crash in "irreducible" test case from PR56262.
[Bug c++/56359] New: [4.8 regression] Bogus "error: no matching function for call to ..."
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56359
Bug #: 56359
Summary: [4.8 regression] Bogus "error: no matching function
for call to ..."
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Google ref b/8213841
Test case reduced from nodejs/src/node_io_watcher.cc
typedef int (*InvocationCallback) (const int &);
template < typename target_t >
void SetPrototypeMethod (target_t, const char *, InvocationCallback);
class A
{
void Initialize ();
protected:
static int Stop (const int &);
void Stop (); // comment out to make the bug disappear.
};
void
A::Initialize ()
{
SetPrototypeMethod (0, "stop", A::Stop);
}
Compiles fine with gcc-4.7, fails with SVN trunk @196104:
g++ -c t.ii
t.ii: In member function ‘void A::Initialize()’:
t.ii:17:43: error: no matching function for call to ‘SetPrototypeMethod(int,
const char [5], )’
SetPrototypeMethod (0, "stop", A::Stop);
^
t.ii:17:43: note: candidate is:
t.ii:4:6: note: template void SetPrototypeMethod(target_t,
const char*, InvocationCallback)
void SetPrototypeMethod (target_t, const char *, InvocationCallback);
^
t.ii:4:6: note: template argument deduction/substitution failed:
t.ii: In substitution of ‘template void
SetPrototypeMethod(target_t, const char*, InvocationCallback) [with target_t =
int]’:
t.ii:17:43: required from here
t.ii:10:16: error: ‘static int A::Stop(const int&)’ is protected
static int Stop (const int &);
^
t.ii:17:43: error: within this context
SetPrototypeMethod (0, "stop", A::Stop);
^
[Bug c++/56411] New: [4.8 regression] Wrong preprocessor output with -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56411
Bug #: 56411
Summary: [4.8 regression] Wrong preprocessor output with
-std=c++11
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
This is a continuation of PR 52538.
Broke somewhere between r195930(ok) and r196104(broken).
cat t.cc
#define FOO(str) sizeof(""str"")
#define BAR(str) sizeof("" str "")
int main()
{
unsigned long a = FOO("abc");
unsigned long b = BAR("abc");
}
g++ -E /tmp/t.cc | grep sizeof
unsigned long a = sizeof("""abc""");
unsigned long b = sizeof("" "abc" "");
g++ -E -std=c++11 /tmp/t.cc | grep sizeof
unsigned long a = sizeof(""str""); WHAT?
unsigned long b = sizeof("" "abc" "");
[Bug c++/56411] [4.8 regression] Wrong preprocessor output with -std=c++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56411 Paul Pluzhnikov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paul Pluzhnikov 2013-02-20 19:32:02 UTC --- So 'str' is the problem because it begins with 's', and changing it to e.g. xstr fixes the problem. Oh, well.
[Bug c++/56243] [4.8 regression] ICE in tree check: expected field_decl, have identifier_node in fixed_type_or_null, at cp/class.c:6645
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56243
--- Comment #6 from Paul Pluzhnikov 2013-02-23
23:06:18 UTC ---
(In reply to comment #4)
> I think the testcase is invalid
Looks like you are right, and it's been over-reduced.
> Shouldn't the below line be diagnosed, even if it is in a template ?
> F& name = x->value;
The error being that typeof(x->value) is A, not F, right?
If so, this corrected test case still triggers ICE:
class A
{
virtual int String ();
};
class F: public A { };
template < typename V > class G
{
V value;
};
class D
{
template < int N > void Verify() {
G* x = 0;
F& name = x->value;
name.String();
}
};
[Bug c/56566] New: bogus "is narrower than values of its type" warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56566
Bug #: 56566
Summary: bogus "is narrower than values of its type" warning
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Test:
struct S {
enum E {
N = -1,
Z = 0
} e : 1;
};
int main() { return 0; }
Using current trunk (r196526):
gcc -c tt.c
tt.c:5:3: warning: ‘e’ is narrower than values of its type [enabled by default]
} e : 1;
^
g++ -c tt.c
tt.c:5:9: warning: ‘S::e’ is too small to hold all values of ‘enum S::E’
[enabled by default]
} e : 1;
^
7.2/7 of the C++ standard says
for an enumeration where emin is the smallest enumerator and emax is the
largest, the values of the enumeration are the values in the range bmin to
bmax, defined as follows: Let K be 1 for a two’s complement representation
and 0 for a one’s complement or sign-magnitude representation. bmax is the
smallest value greater than or equal to max(|emin| − K, |emax|) and equal to
2^M − 1, where M is a non-negative integer. bmin is zero if emin is non-
negative and −(bmax + K) otherwise. The size of the smallest bit-field large
enough to hold all the values of the enumeration type is max(M, 1) if bmin
is
zero and M + 1 otherwise.
given emin = -1, emax = 0, K = 1
then max(|emin|-K,|emax|) = max(0,0) = 0
therefore bmax = 0, M = 0, bmin = -(bmax+K) = -1, size = M+1 = 1
[Bug c/56589] New: [4.8 regression] Array bounds violation is very end-user unfriendly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56589
Bug #: 56589
Summary: [4.8 regression] Array bounds violation is very
end-user unfriendly
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Consider this program with undefined behavior:
#include
typedef int Array[3][2];
void bar (Array a)
{
int i, j;
for (i = 0; i < 3; ++i)
for (j = 0; j < 2; ++j)
printf (" %d", a[i][j]);
puts("");
}
void foo ()
{
Array a;
int j;
for (j = 0; j < 6; ++j) {
a[0][j] = 1; // User hand-optimized two loops into one :-(
}
bar (a);
}
int main ()
{
foo ();
return 0;
}
With gcc-4.7, this produces:
gcc overflow.c && ./a.out
1 1 1 1 1 1
gcc overflow.c -O2 && ./a.out
1 1 1 1 1 1
With gcc-4.8 (r196557):
gcc overflow.c && ./a.out
1 1 1 1 1 1
gcc overflow.c -O2 && ./a.out
1 1 4195396 0 -263006800 32767
No warnings are emitted with -Wall and -Wextra.
The disassembly for foo() shows that only the first two elements of the array
are initialized:
subq$40, %rsp
movq%rsp, %rdi
movl$1, (%rsp)
movl$1, 4(%rsp)
callbar
addq$40, %rsp
ret
I've now seen 3 instances of similar buggy code in our code base, and the loop
there was transformed into an infinite loop instead.
This way of signaling the problem to end-user is *exceedingly* unfriendly.
[Bug c/56607] New: [4.8 regression] GCC fails to warn on division by zero
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56607
Bug #: 56607
Summary: [4.8 regression] GCC fails to warn on division by zero
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Test:
typedef unsigned long size_t;
#ifdef TEST1
int ShouldntCompile ()
{
return 1 / ((sizeof(int) / 3) - 1);
}
#endif
#ifdef TEST2
int WontCompile ()
{
const int x = (sizeof(int) / 3) - 1;
return 1 / x;
}
#endif
Using gcc-4.7:
gcc -Werror -c -DTEST1 as.c ; echo $?
as.c: In function 'ShouldntCompile':
as.c:6:12: error: division by zero [-Werror=div-by-zero]
cc1: all warnings being treated as errors
1
g++ -Werror -c -DTEST1 as.c ; echo $?
# same as above
gcc -Werror -c -DTEST2 as.c ; echo $?
0 # problem
g++ -Werror -c -DTEST2 as.c ; echo $?
as.c: In function 'int WontCompile()':
as.c:14:14: error: division by zero [-Werror=div-by-zero]
cc1plus: all warnings being treated as errors
1
Using gcc-4.8 (r196619):
gcc -Werror -c -DTEST1 as.c; echo $?
as.c: In function 'ShouldntCompile':
as.c:6:12: error: division by zero [-Werror=div-by-zero]
return 1 / ((sizeof(int) / 3) - 1);
^
cc1: all warnings being treated as errors
1
g++ -Werror -c -DTEST1 as.c; echo $?
0 # 4.8 regression, used to warn.
gcc -Werror -c -DTEST2 as.c ; echo $?
0 # still a problem
g++ -Werror -c -DTEST2 as.c; echo $?
as.c: In function 'int WontCompile()':
as.c:14:14: error: division by zero [-Werror=div-by-zero]
return 1 / x;
^
cc1plus: all warnings being treated as errors
1
[Bug c++/56641] New: [4.7/4.8 regression] Bogus warning: 'A' has a field 'A::e' whose type uses the anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56641
Bug #: 56641
Summary: [4.7/4.8 regression] Bogus warning: 'A' has a field
'A::e' whose type uses the anonymous namespace
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
This one is recent regression of gcc-4_7 branch.
Confirmed with current trunk r196749.
namespace {
#1 "foo.cc"
enum E { };
}
struct A
{
enum E e;
};
g++ -c foo.ii
foo.cc:4:8: warning: ‘A’ has a field ‘A::e’ whose type uses the anonymous
namespace [enabled by default]
Deleting the '#1 "foo.cc"' line makes the warning go away.
[Bug c++/56641] [4.7/4.8 regression] Bogus warning: 'A' has a field 'A::e' whose type uses the anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56641
Paul Pluzhnikov changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
--- Comment #2 from Paul Pluzhnikov 2013-03-17
19:42:28 UTC ---
Thanks for the explanation.
The actual use case looks like this:
// test-skeleton.cc
namespace { enum E { }; }
struct A { E e; };
//... other common test skeleton code ...
// foo-test.cc
#include "test-skeleton.cc"
//... specific foo tests
The workaround is to either make 'enum E' global, or name the namespace.
[Bug c++/56757] New: ICE in int_cst_value/get_non_default_template_args_count on invalid source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56757
Bug #: 56757
Summary: ICE in
int_cst_value/get_non_default_template_args_count on
invalid source
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
While doing creduce for something else, I noticed that current trunk (r197163)
dumped core on invalid reduction.
I then creduce'd the invalid to this gibberish:
/// --- cut ---
namespace std template < class, class > struct pair;
struct less struct _Select1st
}
template < typename, typename, typename, typename, typename > class _Rb_tree;
namespace std template < typename _Key, typename _Compare = std:less,
typename _Alloc >
class map
{
typedef _Key key_type
typedef std::pair < >value_type
typedef _Compare key_compare
typedef typename _Alloc::template rebind < value_type >::other
_Pair_alloc_type
typedef _Rb_tree < key_type, value_type, _Select1st,
key_compare, _Pair_alloc_type > _Rep_type
typedef typename _Rep_type::iterator iterator
std::pair < iterator, bool > insert () return
/// --- cut ---
gdb -q cc1plus
(gdb) run pp1.ii 2> /dev/null
Program received signal SIGSEGV, Segmentation fault.
int_cst_value (x=0x0) at ../../gcc/tree.c:10248
10248 unsigned bits = TYPE_PRECISION (TREE_TYPE (x));
(gdb) bt
#0 int_cst_value (x=0x0) at ../../gcc/tree.c:10248
#1 0x005e2ce5 in get_non_default_template_args_count
(args=0x7605f800, flags=) at ../../gcc/cp/error.c:181
#2 0x005eaf99 in dump_template_argument_list
(args=args@entry=0x7605f800, flags=flags@entry=4) at
../../gcc/cp/error.c:190
#3 0x005e4e10 in dump_decl (t=, flags=)
at ../../gcc/cp/error.c:1135
#4 0x005eb689 in dump_typename (t=, flags=) at ../../gcc/cp/error.c:571
#5 0x005eb695 in dump_typename (t=0x760643f0, flags=4) at
../../gcc/cp/error.c:567
#6 0x005eb35b in dump_template_parms (info=,
primary=, flags=4) at ../../gcc/cp/error.c:1647
#7 0x005eb65b in dump_typename (t=0x76064738, flags=4) at
../../gcc/cp/error.c:569
#8 0x005eb35b in dump_template_parms (info=,
primary=, flags=4) at ../../gcc/cp/error.c:1647
#9 0x005e3eb6 in dump_type_prefix (t=, flags=4) at
../../gcc/cp/error.c:783
#10 0x005ede8c in dump_function_decl (t=0x76052c00, flags=4) at
../../gcc/cp/error.c:1406
#11 0x005ef7b1 in decl_as_string (decl=0x76052c00, flags=4) at
../../gcc/cp/error.c:2607
#12 0x00696303 in cxx_printable_name_internal (decl=0x76052c00,
v=2, translate=) at ../../gcc/cp/tree.c:1879
#13 0x00a80473 in announce_function (decl=) at
../../gcc/toplev.c:228
#14 0x0053aae5 in start_preparsed_function (decl1=0x76052c00,
attrs=, flags=) at ../../gcc/cp/decl.c:13071
#15 0x005fe6cc in cp_parser_late_parsing_for_member
(member_function=0x76052c00, parser=0x760611b8) at
../../gcc/cp/parser.c:22419
#16 cp_parser_class_specifier_1 (parser=0x760611b8) at
../../gcc/cp/parser.c:18534
#17 cp_parser_class_specifier (parser=0x760611b8) at
../../gcc/cp/parser.c:18558
#18 cp_parser_type_specifier (parser=parser@entry=0x760611b8,
flags=flags@entry=1, decl_specs=decl_specs@entry=0x7fffd0f0,
is_declaration=is_declaration@entry=true,
declares_class_or_enum=declares_class_or_enum@entry=0x7fffd07c,
is_cv_qualifier=is_cv_qualifier@entry=0x7fffd07b) at
../../gcc/cp/parser.c:13641
#19 0x0061533a in cp_parser_decl_specifier_seq
(parser=parser@entry=0x760611b8, flags=flags@entry=1,
decl_specs=decl_specs@entry=0x7fffd0f0,
declares_class_or_enum=declares_class_or_enum@entry=0x7fffd0ec) at
../../gcc/cp/parser.c:10968
#20 0x006193a4 in cp_parser_single_declaration
(parser=parser@entry=0x760611b8, checks=checks@entry=0x0,
member_p=member_p@entry=false,
explicit_specialization_p=explicit_specialization_p@entry=false,
friend_p=friend_p@entry=0x7fffd1bf)
at ../../gcc/cp/parser.c:22014
#21 0x0061c153 in cp_parser_template_declaration_after_export
(parser=parser@entry=0x760611b8, member_p=) at
../../gcc/cp/parser.c:21899
#22 0x0061c9c0 in cp_parser_template_declaration
(parser=parser@entry=0x760611b8, member_p=member_p@entry=false) at
../../gcc/cp/parser.c:12190
#23 0x00623aaa in cp_parser_declaration
(parser=parser@entry=0x760611b8) at ../../gcc/cp/parser.c:10377
#24 0x0062268e in cp_parser_declaration_seq_opt
(parser=parser@entry=0x760611b8) at ../../gcc/cp/parser.c:10299
#25 0x006228a1 in cp_parser_namespace_body (parser=0x760611b8) at
../.
[Bug c++/56768] New: [4.7] ICE in make_decl_rtl, at varasm.c:1147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56768
Bug #: 56768
Summary: [4.7] ICE in make_decl_rtl, at varasm.c:1147
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Google ref b/8485258
Does *not* reproduce on trunk
Does reproduce using gcc-4_7 (r197167)
Test case:
struct Iter
{
int& operator* ();
void operator++ ();
};
bool operator!= (Iter &, Iter &);
struct Container
{
Iter begin () const;
Iter end () const;
};
struct J
{
virtual J *mutable_child ();
};
struct M
{
M (const Container &);
J ns_;
};
namespace
{
J MakeNamespace (const Container &src)
{
J a;
J *b = 0;
for (const int &c: src)
b = b ? b->mutable_child () : &a;
return a;
}
}
M::M (const Container &ns):ns_ (MakeNamespace (ns))
{
}
cc1plus pp.ii -std=c++11 -quiet && echo ok
ok
cc1plus pp.ii -std=c++11 -quiet -O2
pp.ii: In constructor ‘M::M(const Container&)’:
pp.ii:36:1: internal compiler error: in make_decl_rtl, at varasm.c:1147
Please submit a full bug report,
[Bug c++/56769] New: [4.7] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:2511
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56769
Bug #: 56769
Summary: [4.7] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:2511
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Probably related to PR 56768
Google ref b/8485258
Does *not* reproduce on trunk
Does reproduce using gcc-4_7 (r197167)
Test case:
struct Iter
{
int& operator* ();
void operator++ ();
};
bool operator!= (Iter &, Iter &) { }
struct Container
{
Iter begin () const;
Iter end () const;
};
struct J
{
virtual J *mutable_child ();
};
struct M
{
M (const Container &);
J ns_;
};
namespace
{
J MakeNamespace (const Container &src)
{
J a;
J *b = 0;
for (const int &c: src)
b = b ? b->mutable_child () : &a;
return a;
}
}
M::M (const Container &ns):ns_ (MakeNamespace (ns))
{
}
Note: the only difference from test case in PR 56768 is:
diff pp.ii pp2.ii
7c7
< bool operator!= (Iter &, Iter &);
---
> bool operator!= (Iter &, Iter &) { }
cc1plus pp2.ii -std=c++11 -quiet && echo ok
ok
cc1plus pp2.ii -std=c++11 -quiet -O2
pp2.ii: In constructor ‘M::M(const Container&)’:
pp2.ii:36:1: internal compiler error: in set_ssa_val_to, at
tree-ssa-sccvn.c:2511
Please submit a full bug report,
[Bug c++/56947] New: [4.7.3 regression] Bogus 'XX' was not declared in this scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56947
Bug #: 56947
Summary: [4.7.3 regression] Bogus 'XX' was not declared in this
scope
Classification: Unclassified
Product: gcc
Version: 4.7.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
This is a recent gcc-4_7-branch regression.
The case builds with trunk (r197936), fails with 4.7 branch (r197941):
struct A
{
A (int);
};
template < typename >
void Fn ()
{
const int kCapacity = 0;
struct Q:A
{
Q ():A (kCapacity) { }
};
Q q;
}
template void Fn < int >();
$ trunk/bin/g++ -c t.cc && echo ok
ok
$ 4.7/bin/g++ -c t.cc
t.cc: In instantiation of ‘Fn()::Q::Q() [with = int]’:
t.cc:14:7: required from ‘void Fn() [with = int]’
t.cc:16:26: required from here
t.cc:12:26: error: ‘kCapacity’ was not declared in this scope
[Bug c++/56951] New: Poor diagnostics for error: invalid abstract return type 'XXX'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56951
Bug #: 56951
Summary: Poor diagnostics for error: invalid abstract return
type 'XXX'
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Consider the following test case:
#include
using std::vector;
using std::iterator_traits;
template struct remove_pointer;
template struct remove_pointer { typedef T type; };
template
class iterator_ptr {
typedef typename remove_pointer<
typename iterator_traits::value_type>::type value_type;
value_type Get();
};
class Table;
class F {
typedef iterator_ptr::iterator> iterator;
iterator tables_begin() {}
};
class Table {
virtual void Fn() = 0;
};
This code is accepted by gcc-4.7.x, rejected by current trunk with:
g++ -c tt.cc
tt.cc:13:14: error: invalid abstract return type ‘Table’
value_type Get();
^
tt.cc:23:7: note: because the following virtual functions are pure within
‘Table’:
class Table {
^
tt.cc:24:16: note: virtual void Table::Fn()
virtual void Fn() = 0;
^
I believe the code is in fact invalid.
Note that the error tells me the template line (13), but doesn't tell
what parameters this template was instantiated with, nor what triggered
the instantiation.
Compare to much better error produced when I move 'class Table'
definition ahead of F:
#include
using std::vector;
using std::iterator_traits;
template struct remove_pointer;
template struct remove_pointer { typedef T type; };
template
class iterator_ptr {
typedef typename remove_pointer<
typename iterator_traits::value_type>::type value_type;
value_type Get();
};
class Table {
virtual void Fn() = 0;
};
class F {
typedef iterator_ptr::iterator> iterator;
iterator tables_begin() {}
};
g++ -c tt2.cc
tt2.cc: In instantiation of ‘class
iterator_ptr<__gnu_cxx::__normal_iterator > >’:
tt2.cc:22:27: required from here
tt2.cc:13:14: error: invalid abstract return type ‘Table’
value_type Get();
^
tt2.cc:16:7: note: because the following virtual functions are pure within
‘Table’:
class Table {
^
tt2.cc:17:16: note: virtual void Table::Fn()
virtual void Fn() = 0;
^
[Bug c/56972] New: Missing "may be used uninitialized" warning for "obvious" uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56972
Bug #: 56972
Summary: Missing "may be used uninitialized" warning for
"obvious" uninitialized
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Google ref: b/8616613
// t.c
int f(int x)
{
int ret;
switch (x) {
case 3:
ret = 0;
break;
}
return ret;
}
int main()
{
return f(2);
}
gcc -c -Wall -Wextra t.c
# no output
gcc -c -Wall -Wextra -O2 t.c
# no output
[Bug c/56972] Missing "may be used uninitialized" warning for "obvious" uninitialized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56972 Paul Pluzhnikov changed: What|Removed |Added Severity|normal |enhancement
[Bug c++/57072] New: bogus "is used uninitialized" warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57072
Bug #: 57072
Summary: bogus "is used uninitialized" warning
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Google ref: b/8700048
Test:
struct A {
~A() __attribute__((noreturn));
A& stream();
template void operator<<(T&);
};
struct C {
enum State { S1, S2 };
static bool Fn(State s) {
switch (s) {
case S2: A().stream() << s;
}
}
};
void TestFn()
{
for (int i = 0; i < 2; ++i) {
C::Fn ? (void) 0 : A().stream() << " ";
C::Fn(static_cast(i));
}
}
Using g++ (GCC) 4.9.0 20130412 (experimental) (r197936):
g++ -c -Wuninitialized -O2 -fno-tree-vrp t.cc
t.cc: In function ‘void TestFn()’:
t.cc:16:6: warning: ‘s’ is used uninitialized in this function
[-Wuninitialized]
void TestFn()
^
This warning doesn't trigger on 4_7-branch, but a slightly less reduced test
case does, so it's likely not a recent regression.
[Bug c++/57078] New: Unhelpful -Wunused-variable warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57078
Bug #: 57078
Summary: Unhelpful -Wunused-variable warning
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Test:
namespace Foo {
extern const char Name[]; // line 2
}
int main()
{
using Foo::Name; // trigger, line 7
return 0;
}
Using g++ (GCC) 4.9.0 20130412 (experimental):
g++ -c t.cc -Wall
t.cc: In function ‘int main()’:
t.cc:2:21: warning: unused variable ‘Foo::Name’ [-Wunused-variable]
extern const char Name[];
^
This is quite poor: line 2 that is reported is in some header file, and there
is *nothing* wrong there.
Line 7 may be in a different header file, or in a .cc file, and it is line 7
that triggers the warning; but it is not mentioned in the warning itself.
[Bug tree-optimization/53265] Warn when undefined behavior implies smaller iteration count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53265
--- Comment #27 from Paul Pluzhnikov 2013-04-29
23:18:29 UTC ---
Here is a reduced test case in which g++ (GCC) 4.9.0 20130426 (experimental)
produces infinite loop with -O2 due to aggressive loop optimization, but
doesn't warn (making the bug in user code hard to find).
g++ -O2 test.cc -Wall && ./a.out
Segmentation fault
g++ -O2 test.cc -Wall -fno-aggressive-loop-optimizations && ./a.out && echo ok
ok
struct Puzzle
{
int r[9];
int ignored[18];
} p;
int a, b;
int main()
{
int c = 0;
for (b = 0; b < 27; b++)
{
if (p.r[b] == 0)
c |= p.r[a];
if (c != 0)
return c;
}
return c;
}
[Bug c++/57196] New: [4.8 regression] Bogus "aggregate ... has incomplete type and cannot be defined"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57196
Bug #: 57196
Summary: [4.8 regression] Bogus "aggregate ... has incomplete
type and cannot be defined"
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Google ref: b/8853908
Test case reduced from gUnit.
#include
#include
using std::set;
using std::string;
int& IsNullLiteralHelper(...);
template struct EqHelper { };
void Fn() {
EqHelper{1})>eq1; // ok
EqHelper())> eq2; // ok
EqHelper{"foo"})> eq3; // error
}
Using trunk built at r198689:
g++ -std=c++11 -c tt.cc
tt.cc: In function ‘void Fn()’:
tt.cc:14:60: error: aggregate ‘EqHelper
>(std::initializer_list >{((const
std::basic_string*)(& const std::basic_string
[1]{std::basic_string(((const char*)"foo"), (*(const
std::allocator*)(& std::allocator(})), 1u}, (*(const
std::less >*)(& std::less
>())), (*(const std::allocator >*)(&
std::allocator >())> eq3’ has incomplete type and
cannot be defined
EqHelper{"foo"})> eq3;
^
[Bug c++/57199] New: [4.8, 4.9] Bogus warning: iteration NNNN invokes undefined behavior -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57199
Bug #: 57199
Summary: [4.8, 4.9] Bogus warning: iteration invokes
undefined behavior -Waggressive-loop-optimizations
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Google ref: b/8856275
Test case:
typedef decltype(sizeof(0)) size_t;
struct Foo {
~Foo(); // comment out -> problem disappears
int x[20];
};
template
struct InlinedVector {
inline InlinedVector() : size_(0) { }
inline size_t size() const {
return size_;
}
T* mutable_array();
void resize(size_t n) {
size_t s = size();
DestroyElements(mutable_array() + n, s - n);
}
static void DestroyElements(T* ptr, size_t num) {
for (size_t i = 0; i < num; i++) {
ptr[i].~T();
}
}
size_t size_;
};
struct CP {
void Add();
InlinedVector foo_;
};
void CP::Add() {
foo_.resize(foo_.size() + 1);
}
Using trunk r198689:
g++ -std=c++11 -O2 -c tt.cc
tt.cc: In member function ‘void CP::Add()’:
tt.cc:21:7: warning: iteration 230584300921369396ul invokes undefined behavior
[-Waggressive-loop-optimizations]
ptr[i].~T();
^
tt.cc:20:5: note: containing loop
for (size_t i = 0; i < num; i++) {
^
[Bug c/57200] New: [4.8/4.9] aggressive-loop-optimizations notes appear even when warning itself is suppressed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57200
Bug #: 57200
Summary: [4.8/4.9] aggressive-loop-optimizations notes appear
even when warning itself is suppressed
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Test:
int x[10];
void fn ()
{
int i;
for (i = 0; i < 100; ++i)
x[i] = 1;
}
Using trunk at r198689:
gcc -O2 -c t.c
t.c: In function ‘fn’:
t.c:8:10: warning: iteration 10u invokes undefined behavior
[-Waggressive-loop-optimizations]
x[i] = 1;
^
t.c:7:3: note: containing loop
for (i = 0; i < 100; ++i)
^
Looks good. But this doesn't:
gcc -O2 -c t.c -w
t.c: In function ‘fn’:
t.c:7:3: note: containing loop
for (i = 0; i < 100; ++i)
^
A note suddenly appears from "nowhere" :-(
[Bug tree-optimization/57199] [4.8/4.9 Regression] Bogus warning: iteration NNNN invokes undefined behavior -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57199
Paul Pluzhnikov changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|INVALID |
--- Comment #2 from Paul Pluzhnikov 2013-05-08
12:55:31 UTC ---
> Thus, the warning, while not 100% helpful, points at a real problem.
There is no real problem in the original source, which reads:
size_t s = size();
if (n < s)
DestroyElements(mutable_array() + n, s - n);
else ...
and produces the same warning.
Here is updated test with above condition; confirmed to still show the warning
with trunk @r198709.
typedef decltype(sizeof(0)) size_t;
struct Foo {
~Foo(); // comment out -> problem disappears
int x[20];
};
template
struct InlinedVector {
inline InlinedVector() : size_(0) { }
inline size_t size() const {
return size_;
}
T* mutable_array();
void resize(size_t n) {
size_t s = size();
if (n < s)
DestroyElements(mutable_array() + n, s - n);
}
static void DestroyElements(T* ptr, size_t num) {
for (size_t i = 0; i < num; i++) {
ptr[i].~T();
}
}
size_t size_;
};
struct CP {
void Add();
InlinedVector foo_;
};
void CP::Add() {
foo_.resize(foo_.size() + 1);
}
[Bug driver/57238] New: GCC passes --gdwarf2 to assembler despite -gdwarf-4 on command line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57238 Bug ID: 57238 Summary: GCC passes --gdwarf2 to assembler despite -gdwarf-4 on command line Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: ppluzhnikov at google dot com I noticed that compiling t.c with '-gdwarf-4', I get: <15> DW_AT_comp_dir: (indirect string, offset: 0x4e): /tmp But compiling t.s, I get: <24> DW_AT_comp_dir: /tmp Looking at 'as' invocation, t.c build results in: as -v --64 -o t.o /tmp/ccSXi0lI.s while t.s results in: as --gdwarf2 -v --64 -o t.o t.s Given that dwarf-4 is now the default, passing --gdwarf2 to as is the wrong thing to do, especially given -gdwarf-4 on command line. This was with trunk GCC built @r198709, native Linux/x86_64 build, configured with: --enable-linker-build-id --disable-lto --with-linker-hash-style=gnu --enable-languages=c,c++,go
[Bug driver/57238] GCC passes --gdwarf2 to assembler despite -gdwarf-4 on command line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57238 Paul Pluzhnikov changed: What|Removed |Added CC||ccoutant at google dot com --- Comment #1 from Paul Pluzhnikov --- Hmm, it appears that the current binutils 'as' doesn't know how to generate -gdwarf-4, so it should be fixed first. Cary?
[Bug driver/57238] GCC passes --gdwarf2 to assembler despite -gdwarf-4 on command line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57238 --- Comment #3 from Paul Pluzhnikov --- (In reply to Andrew Pinski from comment #2) > I don't see how this is wrong. It's wrong to emit dwarf2 because I asked for dwarf4 explicitly. > Mixing dwarf4 and dwarf2 should be ok. Ok for what? One of the reasons I ask for dwarf4 is to save on repeated DW_AT_comp_dir strings (which could be quite long). Currently, I do get them merged for all .c and .cc compoilation units, but not for any .s units. That seems broken to me.
[Bug driver/57238] GCC passes --gdwarf2 to assembler despite -gdwarf-4 on command line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57238 Paul Pluzhnikov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from Paul Pluzhnikov --- (In reply to Cary Coutant from comment #4) > I think what you're really asking for is to have the assembler generate > indirect strings. That can be done without upgrading to DWARF 4. Yes. > While I do agree that the assembler ought to be able to generate DWARF 4 by > now, for the kind of debug output that the assembler generates, I don't > think it's really all that important. True. I've opened binutils http://sourceware.org/bugzilla/show_bug.cgi?id=15457 Closing this one.
[Bug c++/57274] New: [4.8/4.9 Regression] Bogus sequence-point warning in C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57274
Bug ID: 57274
Summary: [4.8/4.9 Regression] Bogus sequence-point warning in
C++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Test case:
#include
void fn (int *data) {
write (1, data++, sizeof (*data));
}
Using trunk GCC:
gcc -c -Wall t.c && echo ok
ok
g++ -c -Wall t.c
t.c: In function ‘void fn(int*)’:
t.c:4:36: warning: operation on ‘data’ may be undefined [-Wsequence-point]
write (1, data++, sizeof (*data));
^
sizeof(*data) does *not* dereference data.
[Bug c++/54293] New: When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54293
Bug #: 54293
Summary: When a reference is bound to subobject of a temporary,
lifetime of the temporary is not extended
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Google reference: b/6996555
"ISO/IEC 14882:2011(E) 12.2.5 [class.temporary]
The temporary to which the reference is bound or the temporary that is the
complete object of a subobject to which the reference is bound persists for the
lifetime of the reference except: [etc]"
With gcc-4.6, the lifetime extension is not happening at all:
FAIL int
FAIL Obj
With gcc-4.7 and 4.8 (rev 190453), lifetime is extended for Obj subobject, but
not for 'int' (or 'char', or other primitive types):
FAIL int
The test:
#include
#include
std::set subobjs;
template
struct ValueHolder {
explicit ValueHolder() {
subobjs.insert(&v);
}
~ValueHolder() {
subobjs.erase(&v);
}
T v;
};
struct Obj { };
bool IsValid(const void* p) {
return subobjs.find(p) != subobjs.end();
}
int main() {
const int& ref_int = ValueHolder().v;
if (!IsValid(&ref_int)) {
std::cout << "FAIL int" << std::endl;
}
const Obj& ref_obj = ValueHolder().v;
if (!IsValid(&ref_obj)) {
std::cout << "FAIL Obj" << std::endl;
}
}
[Bug c++/54293] When a reference is bound to subobject of a temporary, lifetime of the temporary is not extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54293 Paul Pluzhnikov changed: What|Removed |Added CC||aaw at gcc dot gnu.org --- Comment #2 from Paul Pluzhnikov 2012-08-16 23:06:58 UTC --- (In reply to comment #1) > I think this is a dup of bug 54197 or at least related to it. Definitely not a dup. I somewhat doubt it's related. Ollie, you have a GCC build with your patch for PR54197. Could you please check what (if any) effect it has on this test case?
[Bug c/41392] New: gcc.dg/torture/stackalign/builtin-apply-4.c fails with -march=pentium3
GCC built from @151825: gcc-svn-install/bin/gcc -m32 builtin-apply-4.c -O0 -march=pentium3 && ./a.out Aborted (core dumped) -- Summary: gcc.dg/torture/stackalign/builtin-apply-4.c fails with - march=pentium3 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ppluzhnikov at google dot com GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41392
[Bug c++/57317] New: [4.8/4.9] Regression bogus and unsuppressable warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57317
Bug ID: 57317
Summary: [4.8/4.9] Regression bogus and unsuppressable warning:
'YYY' has a base 'ZZZ' whose type uses the anonymous
namespace
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google reference: b/9004062
Quite similar, but not identical to PR 56641.
Test case:
// --- cut ---
# 1 "t.h"
template < typename T > struct integral_c {
static const T value = 0;
};
struct is_reference:integral_c < bool > { };
template < class > struct is_function_ptr_helper { };
template < bool > struct is_function_chooser;
template <> struct is_function_chooser <0 >
{
template < typename T > struct result_:is_function_ptr_helper < T * > { };
};
template < typename T > struct is_function_impl:is_function_chooser <
is_reference::value >::result_ < T > { };
#5 "t.cc"
namespace
{
class NonCloneable;
void fn1 ()
{
is_function_impl < NonCloneable > i;
}
}
// --- cut ---
Using current (r199023) trunk:
g++ -c t.ii
t.h: In instantiation of 'struct
is_function_chooser::result_<{anonymous}::NonCloneable>':
t.h:13:32: required from 'struct is_function_impl<{anonymous}::NonCloneable>'
t.cc:10:39: required from here
t.h:10:34: warning:
'is_function_chooser::result_<{anonymous}::NonCloneable>' has a base
'is_function_ptr_helper<{anonymous}::NonCloneable*>' whose type uses the
anonymous namespace [enabled by default]
Richard Smiths says:
I think GCC is upset that a type defined outside of the main source file
has a template argument that has internal linkage.
In principle, that's a valuable diagnostic: it's trying to tell you that
every time you include that header, you're going to get a different type,
and you're likely to have an ODR diagnostic.
However, in this case, it's a false positive, because this happened
while instantiating a template from the main source file (with a type
defined in the main source file, no less).
In addition, this warning isn't suppressable via -Wno-... parameter.
[Bug c++/57319] New: [4.8/4.9] Regression: bogus "defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ..."
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57319
Bug ID: 57319
Summary: [4.8/4.9] Regression: bogus "defaulted move assignment
for ... calls a non-trivial move assignment operator
for virtual base ..."
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google reference: b/9004260
Test case:
class A { };
class B: virtual A { };
class C: virtual B { };
class D: C
{
void operator= (D &);
};
Using current trunk (@r199023):
g++ -c t.ii -std=c++11
t.ii:3:7: warning: defaulted move assignment for ‘C’ calls a non-trivial move
assignment operator for virtual base ‘B’ [-Wvirtual-move-assign]
class C: virtual B { };
^
Richard Smith writes:
The problem is that a defaulted move assignment for a class with two
inheritance paths to a virtual base may move-assign that virtual base
multiple times (and thus may lose state).
However, this particular case *isn't* the problematic case, because
(a) this sample code should not trigger the definition of C's move
assignment operator, and
(b) there is only one inheritance path from C to B, so it won't be
move-assigned multiple times, and
(c) the issue isn't with *non-trivial* move assignments, it's with
*user-provided* move-assignments (for the virtual base or any of its
subobjects), which B does not have.
=> This is a false positive.
[Bug c++/57325] New: [4.7/4.8/4.9 Regression] ICE in strip_typedefs, at cp/tree.c:1306
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57325
Bug ID: 57325
Summary: [4.7/4.8/4.9 Regression] ICE in strip_typedefs, at
cp/tree.c:1306
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google reference: b/9018720
Compiles fine with with gcc-4.6 and Clang.
ICE's with 4.7, 4.8, 4.9 (current trunk @r199023):
g++ -c test.ii
test.ii: In instantiation of ‘void TestJets(JetsT*) [with JetsT =
SimpleJets]’:
test.ii:37:17: required from here
test.ii:25:27: internal compiler error: in strip_typedefs, at cp/tree.c:1306
scoped_ptr < JetT[] > a;
^
0x6b1af0 strip_typedefs(tree_node*)
../../gcc/cp/tree.c:1306
0x55736c canonicalize_type_argument
../../gcc/cp/pt.c:6151
0x57f12d coerce_template_parms
../../gcc/cp/pt.c:6722
0x587878 lookup_template_class_1
../../gcc/cp/pt.c:7286
0x587878 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:7583
0x58ced1 tsubst_aggr_type
../../gcc/cp/pt.c:9844
0x5805b5 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:11183
0x591021 tsubst_decl
../../gcc/cp/pt.c:10655
0x580cf4 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:11104
0x576a9f tsubst_expr
../../gcc/cp/pt.c:12934
0x57605b tsubst_expr
../../gcc/cp/pt.c:12883
0x576e34 tsubst_expr
../../gcc/cp/pt.c:13073
0x574a0b instantiate_decl(tree_node*, int, bool)
../../gcc/cp/pt.c:19108
0x5aff5f instantiate_pending_templates(int)
../../gcc/cp/pt.c:19207
0x5eaef9 cp_write_global_declarations()
../../gcc/cp/decl2.c:4037
Please submit a full bug report,
test.ii:
class valarray { int _M_data; };
template < typename > struct SimpleJet { valarray partials; };
template < class C > struct scoped_ptr_impl
{
scoped_ptr_impl (C *):data_ () { }
struct Data
{
C ptr;
};
Data data_;
};
template < class, class = int >struct scoped_ptr;
template < class C, class D > struct scoped_ptr
{
scoped_ptr ():impl_ (0) { }
scoped_ptr_impl < C > impl_;
};
template < typename JetsT > void
TestJets (JetsT *)
{
typedef typename JetsT::JetType JetT;
scoped_ptr < JetT[] > a;
}
template < typename T > struct SimpleJets
{
typedef SimpleJet < T > JetType;
scoped_ptr < SimpleJet < T >[] > vars_;
};
void fn ()
{
SimpleJets < double >b;
TestJets (&b);
}
[Bug tree-optimization/57199] [4.8/4.9 Regression] Bogus warning: iteration NNNN invokes undefined behavior -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57199 --- Comment #4 from Paul Pluzhnikov --- (In reply to Jakub Jelinek from comment #3) > it can't prove the following loop that uses _8 as upper bound is dead, ... Do we need a separate "may invoke undefined behavior" warning? In our codebase of 100+ million lines of C++, we've found ~20 instances of real "invokes undefined behavior" (so we don't want to turn the -Waggressive-loop-optimizations off). But we also have ~5 instances where the warning is bogus, and there is no easy way to turn them off, short of sprinkling -Wno-aggresive-loop-optimizations over our BUILD files.
[Bug tree-optimization/57199] [4.8/4.9 Regression] Bogus warning: iteration NNNN invokes undefined behavior -Waggressive-loop-optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57199 Paul Pluzhnikov changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Paul Pluzhnikov --- > perhaps some __builtin_unreachable assert that size isn't (size_t) -1? That works. Thanks for the suggestion.
[Bug c++/57376] New: Bogus error due to failure of unqualified namespace lookup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57376
Bug ID: 57376
Summary: Bogus error due to failure of unqualified namespace
lookup
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Reproduced with current trunk @r199204.
g++ -c t.cc
t.cc:17:25: error: ‘F2’ is neither function nor member function; cannot be
declared friend
friend Foo *Foo::F2(Woo *); // error
^
t.cc:17:22: error: expected ‘;’ at end of member declaration
friend Foo *Foo::F2(Woo *); // error
^
t.cc:17:29: error: expected ‘)’ before ‘*’ token
friend Foo *Foo::F2(Woo *); // error
^
Source appears to be completely kosher and is accepted by Clang and EDG.
Test case:
/// --- cut ---
namespace B
{
class Woo;
}
struct Foo
{
Foo* F1(B::Woo *);
Foo* F2(B::Woo *);
};
namespace B
{
class Boo:Foo
{
friend Foo *Foo::F1(B::Woo *); // ok
friend Foo *Foo::F2(Woo *); // error
};
}
/// --- cut ---
[Bug c++/57319] [4.8 Regression]: bogus "defaulted move assignment for ... calls a non-trivial move assignment operator for virtual base ..."
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57319 --- Comment #3 from Paul Pluzhnikov --- Thanks for the fix. Confirmed for both the reduced test case, and the original source. Can this be back-ported to 4.8 branch?
[Bug c++/57317] [4.8/4.9 Regression] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57317 --- Comment #3 from Paul Pluzhnikov --- (In reply to Jason Merrill from comment #2) > Fixed the false positive for 4.8.1. Did you mean "fixed on trunk" ? On trunk I see 2013-05-20 Jason Merrill PR c++/57317 * decl2.c (determine_visibility): Use PRIMARY_TEMPLATE_P to decide whether a template has its own args. but nothing on 4_8-branch. Can this be back-ported to 4.8? Thanks,
[Bug c++/57317] [4.8/4.9 Regression] bogus and unsuppressible warning: 'YYY' has a base 'ZZZ' whose type uses the anonymous namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57317 --- Comment #5 from Paul Pluzhnikov --- (In reply to Jason Merrill from comment #4) > Look again; it's commit 199104 on gcc-4_8-branch. I can see it now. Thanks for the fix!
[Bug c++/56757] ICE in int_cst_value/get_non_default_template_args_count on invalid source
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56757 Paul Pluzhnikov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Paul Pluzhnikov --- Doesn't reproduce for me either using r199204.
[Bug rtl-optimization/57459] LRA inheritance bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57459 --- Comment #1 from Paul Pluzhnikov --- Google ref: b/9070967 This is a 4.8/4.9 regression. We have ~300 test cases (out of 500,000) that are all failing (in i386 mode only) due to this bug.
[Bug c++/57493] New: Incorrect name lookup for range loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57493
Bug ID: 57493
Summary: Incorrect name lookup for range loop
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
This appears to have been broken since 4.6.
Test case:
#include
int main() {
std::vector var;
for (int var : var) {
}
}
Using trunk at r199570:
g++ -c b.cc -std=c++11
b.cc: In function ‘int main()’:
b.cc:5:17: error: no matching function for call to ‘begin(int&)’
for (int var : var) {
^
b.cc:5:17: note: candidates are:
...
Google ref: b/9229787
[Bug rtl-optimization/57459] [4.8/4.9 Regression] LRA inheritance bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57459 --- Comment #3 from Paul Pluzhnikov --- Mis-computing strlen() in shipping GCC releases doesn't look like P3 to me. Could anyone please confirm this bug, set priority appropriately, and/or comment on how this should be fixed? Thanks,
[Bug c++/57550] New: [4.8/4.9] Regression: bogus "error ... is private"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57550
Bug ID: 57550
Summary: [4.8/4.9] Regression: bogus "error ... is private"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/9321660
Current trunk (r199768) fails to compile this test when ACCESS is private:
g++ -c proto1.xx.cc -Wall -DACCESS=public && echo OK
OK
g++ -c proto1.xx.cc -Wall -DACCESS=private
proto1.xx.cc: In instantiation of ‘static void Handler::SetPrimitiveHandlers()
[with T = double]’:
proto1.xx.cc:15:53: required from here
proto1.xx.cc:9:36: error: no matching function for call to
‘MakeHandler()’
MakeHandler(Wrapper >);
^
proto1.xx.cc:9:36: note: candidate is:
proto1.xx.cc:2:25: note: template void MakeHandler(bool (*)(T))
template void MakeHandler (bool (T));
^
proto1.xx.cc:2:25: note: template argument deduction/substitution failed:
proto1.xx.cc:12:37: error: ‘static bool Handler::Append(T) [with T = double]’
is private
template static bool Append (T);
^
proto1.xx.cc:9:36: error: within this context
MakeHandler(Wrapper >);
^
/// --- cut ---
template bool Wrapper(double);
template void MakeHandler(bool (T));
class Handler
{
public:
template static void SetPrimitiveHandlers()
{
MakeHandler(Wrapper >);
}
ACCESS :
template static bool Append(T);
};
template void Handler::SetPrimitiveHandlers();
/// --- cut ---
[Bug c++/57550] [4.8/4.9 Regression] bogus "error ... is private"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57550 --- Comment #2 from Paul Pluzhnikov --- (In reply to Andrew Pinski from comment #1) > I think the problem is that you cannot take an address of a private static > function as that would get around access controls. Surely you can in a class member function.
[Bug c++/58032] New: Bogus error: declared using local type ..., is used but never defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58032
Bug ID: 58032
Summary: Bogus error: declared using local type ..., is used
but never defined
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/9771363
Test:
template
struct ResultCallback {
virtual void Run(T) = 0;
};
template
struct FunctionResultCallback: public ResultCallback {
void Run(T a) { }
};
template
ResultCallback*
NewCallback(void (*function)(T))
{
return new FunctionResultCallback;
}
int main(int argc, char** argv) {
struct Bar {
static void Do(Bar*) { }
};
NewCallback(&Bar::Do)->Run(0);
}
Using
g++ (GCC) 4.9.0 20130730 (experimental)
pp.ii:3:16: error: 'void ResultCallback::Run(T) [with T = main(int,
char**)::Bar*]', declared using local type 'main(int, char**)::Bar', is used
but never defined [-fpermissive]
virtual void Run(T) = 0;
^
Broken since at least 4.7
[Bug c++/58053] New: Bogus "error ... is private ... within this context"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58053
Bug ID: 58053
Summary: Bogus "error ... is private ... within this context"
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Test case:
class Foo {
struct Bar { };
friend class F;
};
class F
#ifdef BUG
: public Foo::Bar
#endif
{
void Fn() { Foo::Bar b; }
};
Using "g++ (GCC) 4.9.0 20130730 (experimental)", the test compiles (clearly
Foo::Bar is accessible to F::Fn()), but fails with -DBUG:
t.cc:2:10: error: ‘struct Foo::Bar’ is private
struct Bar { };
^
t.cc:8:17: error: within this context
: public Foo::Bar
^
[Bug c/58066] New: GCC mis-compiles access to TLS variable with -fPIC on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066
Bug ID: 58066
Summary: GCC mis-compiles access to TLS variable with -fPIC on
x86_64
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/10151411
Reproduced with current trunk, but is broken since at least gcc-4.3.1.
On Linux/x86_64, libstdc++.so.6 __cxa_get_globals looks like so:
Dump of assembler code for function __cxa_get_globals:
0x000cb430 <+0>: lea0x233131(%rip),%rdi
0x000cb437 <+7>: callq 0x4f570 <__tls_get_addr@plt>
0x000cb43c <+12>:add$0x0,%rax
0x000cb442 <+18>:retq
This calls external function __tls_get_addr with mis-aligned stack.
__tls_get_addr may itself call malloc, and malloc is user-replaceable,
and may assume that stack is properly aligned (and crash when it isn't).
Trivial test case:
static __thread char ccc;
extern "C" void* __cxa_get_globals() throw()
{
return &ccc;
}
g++ -fPIC -S -O2 t.cc
results in:
__cxa_get_globals:
leaq_ZL3ccc@tlsld(%rip), %rdi
call__tls_get_addr@PLT
addq$_ZL3ccc@dtpoff, %rax
ret
Ian Lance Taylor says:
There is code in the i386 backend that is designed to avoid this.
However, it appears to have only been fully implemented for the GNU2 TLS
descriptor style ...
I suspect that the right fix is to add the line
ix86_tls_descriptor_calls_expanded_in_cfun = true;
to tls_global_dynamic_64_ and tls_local_dynamic_base_64_
in gcc/config/i386/i386.md.
[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 --- Comment #2 from Paul Pluzhnikov --- (In reply to Andrew Pinski from comment #1) > Which most Linux distro default to anyways ... Ubuntu 12.04.1 LTS doesn't. Configuring trunk GCC on it doesn't default to GNU2 TLS either. What is the way to turn it on?
[Bug c++/58053] Bogus "error ... is private ... within this context"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58053 Paul Pluzhnikov changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #2 from Paul Pluzhnikov --- Quoting Richard Smith: The standard used to say this was invalid and now says it's valid, per DR372. This is a g++ bug, at least in C++11 mode and probably also in C++98 mode (things aren't really clear-cut for issues that were resolved post-C++03, but this seems like a clear case of a DR to me). See llvm.org/PR16774 and http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#372
[Bug target/58066] GCC mis-compiles access to TLS variable with -fPIC on x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58066 --- Comment #3 from Paul Pluzhnikov --- (In reply to Paul Pluzhnikov from comment #2) > What is the way to turn it on? Compiling test case with -mtls-dialect=gnu2 does appear to improve the picture: g++ -fPIC -O2 -S t.cc -mtls-dialect=gnu2 __cxa_get_globals: leaq_ZL3ccc@TLSDESC(%rip), %rax call*_ZL3ccc@TLSCALL(%rax) addq%fs:0, %rax ret The indirect call goes to _dl_tlsdesc_dynamic in ld-linux-x86-64.so.2 with misaligned stack, and the latter re-aligns it.
[Bug c++/58156] New: c++11 bogus ambigous overload with variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58156
Bug ID: 58156
Summary: c++11 bogus ambigous overload with variadic template
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref b/10321377
/// --- cut ---
template
void Foo(U&...) {}
template
void Foo(const U&...) {}
void Bar() {
const int a = 0;
Foo(a);
}
/// --- cut ---
The test compiles with Clang, errors with current trunk GCC:
g++ (GCC) 4.9.0 20130814 (experimental)
g++ -c t.cc -std=c++11
t.cc: In function ‘void Bar()’:
t.cc:9:14: error: call of overloaded ‘Foo(const int&)’ is ambiguous
Foo(a);
^
t.cc:9:14: note: candidates are:
t.cc:2:7: note: void Foo(U& ...) [with T = int; U = {const int}]
void Foo(U&...) {}
^
t.cc:5:7: note: void Foo(const U& ...) [with T = int; U = {int}]
void Foo(const U&...) {}
^
Also broken with gcc-4.7.
[Bug libstdc++/58159] unique_ptr::reset should have debug assertion for "self-reset"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58159 Paul Pluzhnikov changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #5 from Paul Pluzhnikov --- Google ref b/6572217
gcc-bugs@gcc.gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58162
Bug ID: 58162
Summary: [C++11] bogus error: use of deleted function
'constexpr A::A(const A&)'
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref b/10272620
/// --- cut ---
struct A {
A();
A(A&&);
};
struct B {
A const a = A();
};
B b;
/// --- cut ---
Using trunk: g++ (GCC) 4.9.0 20130814 (experimental)
g++ -c -std=c++11 t.cc
t.cc: In constructor ‘constexpr B::B()’:
t.cc:6:8: error: use of deleted function ‘constexpr A::A(const A&)’
struct B {
^
t.cc:1:8: note: ‘constexpr A::A(const A&)’ is implicitly declared as deleted
because ‘A’ declares a move constructor or move assignment operator
struct A {
^
t.cc: At global scope:
t.cc:10:3: note: synthesized method ‘constexpr B::B()’ first required here
B b;
^
Analysys by jdennett
This is under 8.5p17 (via other sections... 9.2[Class Members]p4 leads
to 12.6.2, and 12.6.2p8 says "if the entity is a non-static data member
that has a brace-or-equal-initializer, the entity is initialized as
specified in 8.5"), and (I believe) should be the same initialization
as for a local variable declared as
A const a = A();
(All references above are in the C++14 CD.)
8.5p17 says:
"If the destination type is a (possibly cv-qualified) class type:
— If the initialization is direct-initialization, or if it is
copy-initialization where the cv-unqualified version of the source type
is the same class as, or a derived class of, the class of the destination,
constructors are considered."
We're in the case of copy-initialization where the cv-unqualified
version of the source type is A, and the destination type is "const A",
but arguably "the class of the destination" is A (because const A isn't
a class).
So I believe that this should fall into the same case as
direct-initialization, overload resolution should pick the A::A(A&&)
move constructor, and all should be good.
Wild guesses about how this might go wrong in the compiler:
It might be that G++ is checking whether the cv-unqualified version of
the source type is the same as the destination type (rather than the same
as the cv-unqualified version of the destination type, which is the class
here). If so, it would fall into the main case of copy-initialization,
which creates a temporary of the target type. That should still work,
but if the temporary were (incorrectly) considered to be a "const A"
rather than an "A" then initializing from it would attempt to use the
(deleted) copy constructor.
Seeing if changing A(A&&) to A(A const&&) changes anything might be
informative, or having both overloads present.
Changing 'A(A&&);' to 'A(const AA&&);' or adding it as overload does fix
the compilation problem.
Further patch from jdennett:
With the following hack, the testcase compiles.
$ svn diff gcc
Index: gcc/cp/parser.c
===
--- gcc/cp/parser.c (revision 201651)
+++ gcc/cp/parser.c (working copy)
@@ -23002,7 +23002,10 @@
if (BRACE_ENCLOSED_INITIALIZER_P (parsed_arg)
&& CONSTRUCTOR_IS_DIRECT_INIT (parsed_arg))
flags = LOOKUP_NORMAL;
- parsed_arg = digest_init_flags (TREE_TYPE (decl), parsed_arg, flags);
+ // TODO(jdennett): Something better than this, and work out how
+ // to test it.
+ parsed_arg = digest_init_flags (TYPE_MAIN_VARIANT (TREE_TYPE (decl)),
+ parsed_arg, flags);
}
}
[Bug libstdc++/58163] New: [C++11] Pedantic assert on str[str.size()] is wrong in C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58163
Bug ID: 58163
Summary: [C++11] Pedantic assert on str[str.size()] is wrong in
C++11
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref b/10322506
/// --- cut ---
#include
int main()
{
const std::string cs;
std::string s;
if (cs[0] != '\0') return 1;
if (s[0] != '\0') return 2;
return 0;
}
/// --- cut ---
Using trunk gcc g++ (GCC) 4.9.0 20130814 (experimental)
g++ -g t.cc -D_GLIBCXX_DEBUG_PEDANTIC -D_GLIBCXX_DEBUG -std=c++11 && ./a.out
/gcc-svn-install/include/c++/4.9.0/bits/basic_string.h:848:
std::basic_string<_CharT, _Traits, _Alloc>::reference std::basic_string<_CharT,
_Traits, _Alloc>::operator[](std::basic_string<_CharT, _Traits,
_Alloc>::size_type) [with _CharT = char; _Traits = std::char_traits;
_Alloc = std::allocator; std::basic_string<_CharT, _Traits,
_Alloc>::reference = char&; std::basic_string<_CharT, _Traits,
_Alloc>::size_type = long unsigned int]: Assertion '__pos < size()' failed.
In C++98:
21.3.4 basic_string element access [lib.string.access]
const_reference operator[](size_type pos) const;
reference operator[](size_type pos);
Returns: If pos < size(), returns data()[pos]. Otherwise, if pos == size(),
the const version returns charT().
Otherwise, the behavior is undefined. <<== PEDASSERT catches this.
However, in C++11:
21.4.5 basic_string element access [string.access]
const_reference operator[](size_type pos) const;
reference operator[](size_type pos);
Requires: pos <= size().
Returns: *(begin() + pos) if pos < size(), otherwise a reference to an object
of type T with value charT(); the referenced value shall not be modied.
Note removal of undefined behavior.
[Bug libstdc++/58163] [C++11] Pedantic assert on str[str.size()] is wrong in C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58163
--- Comment #3 from Paul Pluzhnikov ---
The fix:
http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=7e66313066525b0ce38e140e6d9c815e19d119bf
I don't believe the test is quite correct:
+// { dg-options "-std=gnu++11 -D_GLIBCXX_DEBUG_PEDANTIC" }
I don't get the assertion (pre-patch) unless I give *both*
-D_GLIBCXX_DEBUG_PEDANTIC *and* -D_GLIBCXX_DEBUG
[Bug c++/58255] New: [C++11] explicit delegating constructor with no arguments wrongly rejected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58255
Bug ID: 58255
Summary: [C++11] explicit delegating constructor with no
arguments wrongly rejected
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/10458361
Test:
struct A {
explicit A() { } // remove explicit -> compiles fine
A(int x) : A() { }
};
Builds with Clang.
Fails using g++ (GCC) 4.9.0 20130827 (experimental):
g++ -c -std=c++11 /tmp/t1.cc -o /tmp/t.o
/tmp/t1.cc: In constructor 'A::A(int)':
/tmp/t1.cc:3:16: error: no matching function for call to 'A::A()'
A(int x) : A() { }
^
/tmp/t1.cc:3:16: note: candidates are:
/tmp/t1.cc:3:3: note: A::A(int)
A(int x) : A() { }
^
/tmp/t1.cc:3:3: note: candidate expects 1 argument, 0 provided
/tmp/t1.cc:1:8: note: constexpr A::A(const A&)
struct A {
^
/tmp/t1.cc:1:8: note: candidate expects 1 argument, 0 provided
/tmp/t1.cc:1:8: note: constexpr A::A(A&&)
/tmp/t1.cc:1:8: note: candidate expects 1 argument, 0 provided
This has been broken since at least gcc-4.7
[Bug c++/58328] [C++11] bogus: error: constructor required before non-static data member for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58328
--- Comment #2 from Paul Pluzhnikov ---
(In reply to Paolo Carlini from comment #1)
> I suspect the error isn't bogus, current clang++ also rejects it.
Hmm, perhaps you are correct. The original test that is *not* rejected by clang
was:
struct A {
struct B {
int x, y = 1;
};
A(const B& opts = B()) {}
};
But perhaps Clang doesn't reject it in error?
[Bug c++/58328] New: [C++11] bogus: error: constructor required before non-static data member for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58328
Bug ID: 58328
Summary: [C++11] bogus: error: constructor required before
non-static data member for
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/10634418
This appears to be very similar to PR 57770
Using g++ (GCC) 4.9.0 20130904 (experimental)
cat t.cc
struct A {
struct B {
// B() {} // Uncommenting this line makes it work.
int y = 1; // Removing initializer makes it work.
};
A(const B& opts = B()) {} // Removing default makes it work.
};
g++ -c t.cc -std=c++11
t.cc: In constructor 'A::B::B()':
t.cc:2:10: error: constructor required before non-static data member for
'A::B::y' has been parsed
struct B {
^
t.cc: At global scope:
t.cc:7:23: note: synthesized method 'A::B::B()' first required here
A(const B& opts = B()) {}
^
[Bug c++/58408] New: [C++11] __thread + trivially_constructible -> error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58408
Bug ID: 58408
Summary: [C++11] __thread + trivially_constructible -> error
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Google ref: b/10727382
This source:
class Test {
public:
Test() = default;
Test(char *b) { }
int i;
};
__thread Test test;
fails to compile with current trunk (g++ (GCC) 4.9.0 20130911 (experimental)):
g++ -c -std=c++11 /tmp/t.c
/tmp/t.cc:8:15: error: non-local variable 'test' declared '__thread' needs
dynamic initialization
__thread Test test;
^
/tmp/t.cc:8:15: note: C++11 'thread_local' allows dynamic initialization and
destruction
I don't see a good reason to reject this source -- the required dynamic
initialization is defaulted.
[Bug libstdc++/58514] Undefined symbol in libstdc++.so starting with rev 202818
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58514 --- Comment #2 from Paul Pluzhnikov --- Fixed by r202832 and r202836. Sorry about the breakage.
[Bug rtl-optimization/50938] x86 alloca adds 15 twice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50938
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot
||com
--- Comment #1 from Paul Pluzhnikov 2011-10-31
17:43:50 UTC ---
This bug prevent glibc's extend_alloca from working as it is intended.
The macro (for _STACK_GROWS_DOWN) is:
# define extend_alloca(buf, len, newlen) \
(__typeof (buf)) ({ size_t __newlen = (newlen); \
char *__newbuf = __alloca (__newlen); \
if (__newbuf + __newlen == (char *) buf)\
len += __newlen; \
else\
len = __newlen; \
__newbuf; })
However due to the +30 adjustment, __newbuf + __newlen == (char *) buf is never
true.
This leads to excessive stack use in glibc under some conditions.
[Bug c++/53220] New: g++ mis-compiles compound literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220
Bug #: 53220
Summary: g++ mis-compiles compound literals
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
This appears to be a gcc-4.7 regression. Confirmed in:
g++ (GCC) 4.8.0 20120331 (experimental)
g++ (GCC) 4.8.0 20120503 (experimental)
#include
int main()
{
for (int *p = (int[]){ 1, 2, 3, 0}; *p; ++p) {
printf("%d\n", *p);
}
return 0;
}
gcc -std=c99 t2.c && ./a.out
1
2
3
gcc -std=c99 -O2 t2.c && ./a.out
1
2
3
g++ t2.c && ./a.out
1
2
3
g++ -O2 -g t2.c && ./a.out
944127552
32767
AFAICT, g++ completely removes the initializer and reads random garbage off
stack:
(gdb) disas main
Dump of assembler code for function main():
0x00400600 <+0>: push %rbx
0x00400601 <+1>: sub$0x10,%rsp
0x00400605 <+5>: mov(%rsp),%esi
0x00400608 <+8>: mov%rsp,%rbx
0x0040060b <+11>:test %esi,%esi
0x0040060d <+13>:je 0x400626
0x0040060f <+15>:nop
0x00400610 <+16>:xor%eax,%eax
0x00400612 <+18>:add$0x4,%rbx
0x00400616 <+22>:mov$0x40071c,%edi
0x0040061b <+27>:callq 0x400478
0x00400620 <+32>:mov(%rbx),%esi
0x00400622 <+34>:test %esi,%esi
0x00400624 <+36>:jne0x400610
0x00400626 <+38>:add$0x10,%rsp
0x0040062a <+42>:xor%eax,%eax
0x0040062c <+44>:pop%rbx
0x0040062d <+45>:retq
End of assembler dump.
valgrind ./a.out
...
==13572== Conditional jump or move depends on uninitialised value(s)
==13572==at 0x40060D: main (/tmp/t2.c:5)
==13572==
==13572== Use of uninitialised value of size 8
==13572==at 0x5625E4B: _itoa_word
(/build/buildd/eglibc-2.11.1/stdio-common/_itoa.c:195)
==13572==by 0x5628A87: vfprintf
(/build/buildd/eglibc-2.11.1/stdio-common/vfprintf.c:1616)
==13572==by 0x5631659: printf
(/build/buildd/eglibc-2.11.1/stdio-common/printf.c:35)
==13572==by 0x40061F: main (/tmp/t2.c:6)
==13572==
==13572== Conditional jump or move depends on uninitialised value(s)
==13572==at 0x5625E55: _itoa_word
(/build/buildd/eglibc-2.11.1/stdio-common/_itoa.c:195)
==13572==by 0x5628A87: vfprintf
(/build/buildd/eglibc-2.11.1/stdio-common/vfprintf.c:1616)
==13572==by 0x5631659: printf
(/build/buildd/eglibc-2.11.1/stdio-common/printf.c:35)
==13572==by 0x40061F: main (/tmp/t2.c:6)
==13572==
==13572== Conditional jump or move depends on uninitialised value(s)
==13572==at 0x5627ED2: vfprintf
(/build/buildd/eglibc-2.11.1/stdio-common/vfprintf.c:1616)
==13572==by 0x5631659: printf
(/build/buildd/eglibc-2.11.1/stdio-common/printf.c:35)
==13572==by 0x40061F: main (/tmp/t2.c:6)
==13572==
==13572== Conditional jump or move depends on uninitialised value(s)
==13572==at 0x5627EF0: vfprintf
(/build/buildd/eglibc-2.11.1/stdio-common/vfprintf.c:1616)
==13572==by 0x5631659: printf
(/build/buildd/eglibc-2.11.1/stdio-common/printf.c:35)
==13572==by 0x40061F: main (/tmp/t2.c:6)
==13572==
-16780368
==13572== Conditional jump or move depends on uninitialised value(s)
==13572==at 0x400624: main (/tmp/t2.c:5)
==13572==
127
...
Google ref: b/6439133
[Bug c++/53220] g++ mis-compiles compound literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220 --- Comment #1 from Paul Pluzhnikov 2012-05-03 19:53:07 UTC --- gcc-compiled code for reference: (gdb) disas main Dump of assembler code for function main: 0x00400540 <+0>: push %rbp 0x00400541 <+1>: mov$0x1,%esi 0x00400546 <+6>: mov$0x2,%ebp 0x0040054b <+11>:push %rbx 0x0040054c <+12>:sub$0x18,%rsp 0x00400550 <+16>:movl $0x1,(%rsp) <<=== 0x00400557 <+23>:movl $0x2,0x4(%rsp)<<=== 0x0040055f <+31>:mov%rsp,%rbx 0x00400562 <+34>:movl $0x3,0x8(%rsp)<<=== 0x0040056a <+42>:movl $0x0,0xc(%rsp)<<=== 0x00400572 <+50>:jmp0x40057d 0x00400574 <+52>:nopl 0x0(%rax) 0x00400578 <+56>:mov%ebp,%esi 0x0040057a <+58>:mov0x4(%rbx),%ebp 0x0040057d <+61>:xor%eax,%eax 0x0040057f <+63>:mov$0x40068c,%edi 0x00400584 <+68>:add$0x4,%rbx 0x00400588 <+72>:callq 0x4003b8 0x0040058d <+77>:test %ebp,%ebp 0x0040058f <+79>:jne0x400578 0x00400591 <+81>:add$0x18,%rsp 0x00400595 <+85>:xor%eax,%eax 0x00400597 <+87>:pop%rbx 0x00400598 <+88>:pop%rbp 0x00400599 <+89>:retq End of assembler dump.
[Bug c++/53220] [4.7/4.8 Regression] g++ mis-compiles compound literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220 --- Comment #6 from Paul Pluzhnikov 2012-05-07 16:28:56 UTC --- (In reply to comment #5) > 1) to keep the current G++ semantics of compound literals, but change its > behavior due to the implementation change (with clobber marker); I would argue that 1 is completely useless for "you can also construct an array" use case from http://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html It always initializes the pointer with dangling storage, and is always a bug. If "keep the current g++ semantics", then the code should be rejected at compile time, and should *not* work when built without optimization. IMO, having this code working in C and not working in C++ is a lousy choice.
[Bug c++/53368] New: [4.7/4.8 regression] c++11 reject-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53368
Bug #: 53368
Summary: [4.7/4.8 regression] c++11 reject-valid-code
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
We've noticed this using 4.7 branch, confirmed exists in current trunk,
does not appear to exist in 4.6.
/// --- cut ---
// g++ -c -std=c++11 t.cc
// Fails: g++ (GCC) 4.8.0 20120515 (experimental)
class Message; // comment out -> works
namespace proto {
struct Message {
virtual void Copy(const Message&);
};
}
struct MessageSet: public proto::Message {
// using Message::Copy; // this works
using proto::Message::Copy;
};
/// --- cut ---
$ g++ -c t.cc
$ g++ -c t.cc -std=c++11
t.cc:15:25: error: type 'Message' is not a base type for type 'MessageSet'
using proto::Message::Copy;
^
[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841 Paul Pluzhnikov changed: What|Removed |Added CC||ppluzhnikov at google dot ||com --- Comment #13 from Paul Pluzhnikov 2012-05-16 03:09:56 UTC --- *** Bug 53368 has been marked as a duplicate of this bug. ***
[Bug c++/53368] [4.7/4.8 regression] c++11 reject-valid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53368 Paul Pluzhnikov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Paul Pluzhnikov 2012-05-16 03:09:56 UTC --- Yes, looks like a dup of 52841. *** This bug has been marked as a duplicate of bug 52841 ***
[Bug c++/53220] [4.7/4.8 Regression] g++ mis-compiles compound literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220 --- Comment #11 from Paul Pluzhnikov 2012-05-17 00:02:33 UTC --- (In reply to comment #10) > C++98 and C++11 define the lifetime of a temporary as lasting until the end of > the full-expression, unless its lifetime is extended by binding it to a > reference. G++ treats compound literals as temporaries like any other. So, as far as I understand: 1. the example with literal arrays in the documentation is invalid in C++, 2. I should fix C++ code that uses them 3. all that remains in this bug is to issue diagnostics for them
[Bug c++/53220] [4.7/4.8 Regression] g++ mis-compiles compound literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220 --- Comment #13 from Paul Pluzhnikov 2012-05-22 17:49:24 UTC --- (In reply to comment #12) > So yes, what remains for this bug is to complain about undefined behavior due > to accessing the value of an object after its lifetime has ended. The documentation here: http://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html sould probably be updated to mention that the "You can also construct an array" part only works in C, and leads to undefined behavior in C++.
[Bug c++/53220] [4.7/4.8 Regression] g++ mis-compiles compound literals
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53220 --- Comment #13 from Paul Pluzhnikov 2012-05-22 17:49:24 UTC --- (In reply to comment #12) > So yes, what remains for this bug is to complain about undefined behavior due > to accessing the value of an object after its lifetime has ended. The documentation here: http://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html sould probably be updated to mention that the "You can also construct an array" part only works in C, and leads to undefined behavior in C++. --- Comment #14 from Paul Pluzhnikov 2012-05-22 17:50:07 UTC --- (In reply to comment #12) > So yes, what remains for this bug is to complain about undefined behavior due > to accessing the value of an object after its lifetime has ended. The documentation here: http://gcc.gnu.org/onlinedocs/gcc/Compound-Literals.html should probably be updated to mention that the "You can also construct an array" part only works in C, and leads to undefined behavior in C++.
[Bug c++/53524] New: [4.7/4.8 Regression] Bogus and unsupressable enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524
Bug #: 53524
Summary: [4.7/4.8 Regression] Bogus and unsupressable enum
comparison warning
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ppluzhni...@google.com
Created attachment 27519
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27519
test case
Test case reduced from llvm/utils/TableGen/AsmMatcherEmitter.cpp
First noticed in gcc-4.7, confirmed in 4.8.0 20120515.
In template metaprogramming, it is quite common to compare enum values from
different instantiations of the same template.
GCC-4.7 started to warn about some of them. Further, the warning doesn't get
suppressed even under -Wno-enum-compare.
There is also a secondary problem: the diagnostic emitted is particularly lousy
-- it points to the enum itself, leaving no clue as to what GCC is complaining
about:
g++ -c tt.cc
tt.cc: In instantiation of ‘struct PointerUnionUIntTraits’:
tt.cc:10:8: required from ‘struct
PointerIntPair
>’
tt.cc:23:9: required from ‘class PointerUnion’
tt.cc:27:61: required from here
tt.cc:14:8: warning: enumeral mismatch in conditional expression:
‘PointerLikeTypeTraits::’ vs
‘PointerLikeTypeTraits::’ [enabled by
default]
enum {
^
[Bug c++/52841] [4.7/4.8 Regression] error: type 'Solvable' is not a base type for type 'Resolvable'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52841
--- Comment #15 from Paul Pluzhnikov 2012-05-30
19:13:02 UTC ---
I've got another small reproducer, that shows up as a slightly different
failure, but very likely is the same problem:
namespace util { } // comment out => problem disappears
namespace foo {
namespace util {
struct Printer {
struct Convert {
};
};
class XPrinter: Printer {
// using ::foo::util::Printer::Convert; // ok
// using Printer::Convert; // ok
using foo::util::Printer::Convert; // error
};
}
}
g++ --version
g++ (GCC) 4.8.0 20120515 (experimental)
g++ -c pp.ii -std=c++11
pp.ii:13:24: error: ‘util::Printer’ has not been declared
using foo::util::Printer::Convert; // error
g++ -c pp.ii -std=c++98 && echo ok
ok
[Bug c++/53524] [4.7/4.8 Regression] Bogus and unsuppressible enum comparison warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53524
--- Comment #19 from Paul Pluzhnikov 2012-05-31
21:33:51 UTC ---
(In reply to comment #16)
> In any case I recommend not mixing together here different issues:
I don't believe there are separate issues here.
> the first
> one, subject of this report, is overeager warning in open enum context with
> conditional operators
Yes, that warning is overeager *in that context*, i.e. it fires on correct
code. Further, that code is quite common in template metaprogramming,
and we've had it fire in several different packages.
> (I understand that by now we agree that the warning is
> behaving as designed,
I don't believe we agree on that.
The warning itself is good (behaving as designed) in this context:
enum { A };
enum { B };
return 0 ? A : B; // bug
I wouldn't want to suppress that warning above.
But I would *have* to suppress it (we build with -Werror), if it also fires
in the open enum context, where it does *not* behave as designed.
And that would be quite undesireable.
> only it seems sensible to have a way to at least
> controlling it, cmp C front end, EDG); the second one is about speculative
> defects in the way the C++ front end handles enumerated types. For the latter
> we need testcases in Bugzilla, actually a separate PR should be opened.
The second issue you are referring to is really just an explanation of
why the code that generates the warning is doing so: it has been given
bad data.
In comment#15, Lawrence suggested an approach ("Second, ...") that would
avoid giving bad data to build_conditional_expr_1().
