[Bug libstdc++/56109] Add light-weight ABI-compatible debug checks to standard containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56109 Paul Pluzhnikov changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #5 from Paul Pluzhnikov --- Already covered by PR 86843 and PR 56103.
[Bug libstdc++/83029] Memory leaks due to leaked thread local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83029 --- Comment #5 from Paul Pluzhnikov --- (In reply to Jonathan Wakely from comment #4) > Which version of glibc are you using? "Debian GLIBC 2.24-12". I believe this bug should be closed as fixed or invalid: 1. The original test case does not fail on this system, and produces expected matching constructors / destructors: Constructing printer. Constructing printer. Printing something... Destroying printer... Printing something... Destroying printer... 2. The test case from #c2 is quite different (because thread_local is in function scope rather than the global scope), and is actually a (hard to spot) bug in the test case. Analysis by richardsm...@google.com: "The program references a function-static local variable without ever having executed its initializer." (This happens because function-local thread_local variables are initialized when they are reached, just like function-local static variables, and that never happens in the test case from #c2)
[Bug libstdc++/83029] Memory leaks due to leaked thread local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83029 --- Comment #3 from Paul Pluzhnikov --- Reconfirmed with today trunk (r270470).
[Bug libstdc++/83029] Memory leaks due to leaked thread local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83029
Paul Pluzhnikov changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
--- Comment #2 from Paul Pluzhnikov ---
We just hit the same bug. Confirmed in 9.0.1 20190216 (experimental) -- the
latest trunk build I have.
Trivial test case (similar to the original, but makes it easy to tell what's
going on).
cut
#include
#include
#include
class Box {
public:
explicit Box(const char *s) : s_(s) {}
~Box() {
std::cout << s_ << std::endl;
}
private:
const char *const s_;
};
int main() {
thread_local std::unique_ptr box;
std::cout << "line " << __LINE__ << ": " << << std::endl;
box.reset(new Box("Main thread"));
std::thread thread0([&] {
std::cout << "line " << __LINE__ << ": " << << std::endl;
std::thread thread1([&] {
std::cout << "line " << __LINE__ << ": " << << std::endl;
box.reset(new Box("thread1a"));
box.reset(new Box("thread1b"));
});
thread1.join();
box.reset(new Box("thread0A"));
box.reset(new Box("thread0B"));
});
thread0.join();
std::cout << "END" << std::endl;
}
cut
g++ -g -fsanitize=leak -pthread thr.cc && ./a.out
line 18: 0x7f95ae9e02f0
line 23: 0x7f95abeff6f0
line 26: 0x7f95ab6fe6f0
thread1a
thread0A
END
Main thread
=
==207583==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f95ad954840 in operator new(unsigned long)
(/usr/lib/x86_64-linux-gnu/liblsan.so.0+0xf840)
#1 0x558bd33cb127 in operator() /tmp/thr.cc:28
#2 0x558bd33cb6cc in __invoke_impl:: >
/usr/include/c++/7/bits/invoke.h:60
#3 0x558bd33cb411 in __invoke:: >
/usr/include/c++/7/bits/invoke.h:95
#4 0x558bd33cbc5d in _M_invoke<0> /usr/include/c++/7/thread:234
#5 0x558bd33cbc02 in operator() /usr/include/c++/7/thread:243
#6 0x558bd33cbbbd in _M_run /usr/include/c++/7/thread:186
#7 0x7f95ad67cb22 (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xbcb22)
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f95ad954840 in operator new(unsigned long)
(/usr/lib/x86_64-linux-gnu/liblsan.so.0+0xf840)
#1 0x558bd33cb228 in operator() /tmp/thr.cc:33
#2 0x558bd33cb864 in __invoke_impl >
/usr/include/c++/7/bits/invoke.h:60
#3 0x558bd33cb4e2 in __invoke >
/usr/include/c++/7/bits/invoke.h:95
#4 0x558bd33cbc31 in _M_invoke<0> /usr/include/c++/7/thread:234
#5 0x558bd33cbbde in operator() /usr/include/c++/7/thread:243
#6 0x558bd33cbb9d in _M_run /usr/include/c++/7/thread:186
#7 0x7f95ad67cb22 (/usr/lib/x86_64-linux-gnu/libstdc++.so.6+0xbcb22)
SUMMARY: LeakSanitizer: 16 byte(s) leaked in 2 allocation(s).
Here we can observe that:
1. there are 3 separate instances of std::unique_ptr (as expected), but
2. only 1 of these instances is destructed, the other two are leaked.
[Bug demangler/79111] demangle_template tries to allocate 18446744070799748648 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79111 Paul Pluzhnikov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from Paul Pluzhnikov --- Current binutils trunk no longer shows any allocations with bytes > 1024, so looks obsolete to me.
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 --- Comment #9 from Paul Pluzhnikov --- Thanks, H.J. https://sourceware.org/bugzilla/show_bug.cgi?id=5784 has a few references, and in particular https://sourceware.org/ml/libc-alpha/2012-09/msg00192.html is important to consider.
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 --- Comment #6 from Paul Pluzhnikov --- (In reply to Jakub Jelinek from comment #5) > Because it is very expensive. One impractical solution is to require '-pthread' on the compile and link line, and link a libgcc_mt that has non-weak references to pthread_* functions. This will force end users to finally build their programs with correct command line :-)
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 --- Comment #4 from Paul Pluzhnikov --- (In reply to Jakub Jelinek from comment #3) > This is a glibc bug I (obviously) disagree. , coming up with a set of weakref checks for gthr.h that > would satisfy static linking of glibc and all possible combinations of > included vs. non-included objects is impossible. If you call pthread_mutex_lock (or any other function) via weakref, then you should ensure that the function is actually available. AFAICT, libgcc only calls a few pthread_* functions. Why is it hard to check that *all* of them are present? > E.g. Fedora/RHEL ld -r libpthread.a objects into a single exactly because of > this. That is a workaround, not a fix. And it has significant negative effects in the resulting program code size. > There are many dups of this both on the gcc side and glibc side. Well, I think GCC and GLIBC developers need to sit down and decide whose bug it is, and fix it once and for all :-)
[Bug libgcc/87189] libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189 --- Comment #1 from Paul Pluzhnikov --- Crash stack for reference: Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () #1 0x00477f7c in __gthread_mutex_lock (__mutex=0x6a7380 ) at ./gthr-default.h:748 #2 __register_frame_info_bases (begin=, ob=0x6a2300 , tbase=, dbase=) at ../../../libgcc/unwind-dw2-fde.c:103 #3 0x00400acd in frame_dummy () #4 0x0001 in ?? () #5 0x0040194c in __libc_csu_init (argc=-9472, argc@entry=1, argv=argv@entry=0x7fffdc78, envp=0x7fffdc88) at elf-init.c:88 #6 0x00401170 in __libc_start_main (main=0x400add , argc=1, argv=0x7fffdc78, init=0x4018d0 <__libc_csu_init>, fini=0x401970 <__libc_csu_fini>, rtld_fini=0x0, stack_end=0x7fffdc68) at ../csu/libc-start.c:264 #7 0x004009fa in _start () at ../sysdeps/x86_64/start.S:120
[Bug libgcc/87189] New: libgcc/gthr-posix.h (__gthread_active_p) makes unwarranted assumptions about libpthread.a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87189
Bug ID: 87189
Summary: libgcc/gthr-posix.h (__gthread_active_p) makes
unwarranted assumptions about libpthread.a
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Target Milestone: ---
Redirected here from GLIBC bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=21777
A trivial program using pthread_key_create but not pthread_mutex_lock will
crash on GLIBC, when linked statically.
Current code in libgcc/gthr-posix.h:
#ifdef __GLIBC__
__gthrw2(__gthrw_(__pthread_key_create),
__pthread_key_create,
pthread_key_create)
# define GTHR_ACTIVE_PROXY __gthrw_(__pthread_key_create)
assumes that if __pthread_key_create is linked in, then
pthread_mutex_{lock,unlock} will also be (__gthread_active_p() returns 1).
As attached test demonstrates, that is not necessarily the case.
Workaround: add -Wl,-u,pthread_mutex_lock -Wl,-u,pthread_mutex_unlock to the
link line.
Confirmed with current GLIBC trunk (a6e8926f8d49a213a9abb1a61f6af964f612ab7f)
and GCC @264043.
P.S. Why would a program use pthread_key_create but not pthread_mutex_lock?
Suppose you have a piece of data you want to memoize between calls to a certain
function, and that the data needs to be modifiable. It's convenient to make
that data thread-local, so the function is both thread-safe and parallelizable.
--- test.c ---
/* Link with "gcc -pthread test.c -static" */
#include
pthread_key_t k;
int
main (int argc, char *argv[])
{
pthread_key_create (, NULL);
pthread_setspecific (k, NULL);
return 0;
}
[Bug demangler/79111] New: demangle_template tries to allocate 18446744070799748648 bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79111 Bug ID: 79111 Summary: demangle_template tries to allocate 18446744070799748648 bytes Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: ppluzhnikov at google dot com Target Milestone: --- Test case from LLVM libFuzzer. Using current trunk binutils (libiberty identical to current trunk GCC r244514): cxxfilt __H209__nuDD2 cxxfilt: out of memory allocating 18446744070799748648 bytes after a total of 135168 bytes (gdb) b __libc_malloc if bytes > 1 Breakpoint 2 at 0x77893660: file malloc.c, line 2876. (gdb) c Continuing. Breakpoint 2, __GI___libc_malloc (bytes=140737488345896) at malloc.c:2876 2876malloc.c: No such file or directory. (gdb) up 2 #2 0x007bd246 in demangle_template (work=work@entry=0x7fffdba0, mangled=mangled@entry=0x7fffdb28, tname=tname@entry=0x7fffdb40, trawname=trawname@entry=0x0, is_type=is_type@entry=0, remember=remember@entry=0) at ../../libiberty/cplus-dem.c:2232 2232 work->tmpl_argvec = XNEWVEC (char *, r); (gdb) p r $1 = -363725371 (gdb) bt #0 __GI___libc_malloc (bytes=140737488345896) at malloc.c:2876 #1 0x007d1158 in xmalloc (size=18446744070799748648) at ../../libiberty/xmalloc.c:147 #2 0x007bd246 in demangle_template (work=work@entry=0x7fffdba0, mangled=mangled@entry=0x7fffdb28, tname=tname@entry=0x7fffdb40, trawname=trawname@entry=0x0, is_type=is_type@entry=0, remember=remember@entry=0) at ../../libiberty/cplus-dem.c:2232 #3 0x007c05e6 in demangle_signature (work=work@entry=0x7fffdba0, mangled=mangled@entry=0x7fffdb28, declp=declp@entry=0x7fffdb40) at ../../libiberty/cplus-dem.c:1695 #4 0x007c1435 in internal_cplus_demangle (work=work@entry=0x7fffdba0, mangled=0x7fffe0af "_nuDD2", mangled@entry=0x7fffe0a0 "__H209__nuDD2") at ../../libiberty/cplus-dem.c:1261 #5 0x007bc492 in cplus_demangle (mangled=0x7fffe0a0 "__H209__nuDD2", options=11) at ../../libiberty/cplus-dem.c:922 #6 0x00405644 in demangle_it (mangled_name=0x7fffe0a0 "__H209__nuDD2") at ../../binutils/cxxfilt.c:62 #7 0x0040525c in main (argc=2, argv=0x7fffdd88) at ../../binutils/cxxfilt.c:227 Should get_count() check for int overflow?
[Bug demangler/79099] New: Memory leak in cplus-dem.c:2232
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79099 Bug ID: 79099 Summary: Memory leak in cplus-dem.c:2232 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: demangler Assignee: unassigned at gcc dot gnu.org Reporter: ppluzhnikov at google dot com Target Milestone: --- Discovered with LLVM libFuzzer (http://llvm.org/docs/LibFuzzer.html). Using current binutils trunk (libiberty is identical to r244484): valgrind --leak-check=full build/binutils/cxxfilt __ELztype_31__tp__H1f_H1f0U_F0U_Fv__F__ELztype_31__tp__H1f0U_FS (signed) __ELztype_31__tp__H1f_H1f0U_F0U_Fv__F__ELztype_31__tp<0>(void) ==24094== HEAP SUMMARY: ==24094== in use at exit: 9 bytes in 2 blocks ==24094== total heap usage: 33 allocs, 31 frees, 888 bytes allocated ==24094== ==24094== 9 (8 direct, 1 indirect) bytes in 1 blocks are definitely lost in loss record 2 of 2 ==24094==at 0x40307C4: malloc (valgrind/coregrind/m_replacemalloc/vg_replace_malloc.c:270) ==24094==by 0x7D1157: xmalloc (/build/libiberty/../../libiberty/xmalloc.c:147) ==24094==by 0x7BD245: demangle_template (/build/libiberty/../../libiberty/cplus-dem.c:2232) ==24094==by 0x7C05E5: demangle_signature (/build/libiberty/../../libiberty/cplus-dem.c:1695) ==24094==by 0x7C0994: iterate_demangle_function (/build/libiberty/../../libiberty/cplus-dem.c:2747) ==24094==by 0x7C1598: internal_cplus_demangle (/build/libiberty/../../libiberty/cplus-dem.c:2975) ==24094==by 0x7BC491: cplus_demangle (/build/libiberty/../../libiberty/cplus-dem.c:922) ==24094==by 0x405643: demangle_it (/build/binutils/../../binutils/cxxfilt.c:62) ==24094==by 0x40525B: main (/build/binutils/../../binutils/cxxfilt.c:227) ==24094== ==24094== LEAK SUMMARY: ==24094==definitely lost: 8 bytes in 1 blocks ==24094==indirectly lost: 1 bytes in 1 blocks ==24094== possibly lost: 0 bytes in 0 blocks ==24094==still reachable: 0 bytes in 0 blocks ==24094== suppressed: 0 bytes in 0 blocks The same leak was definitely present as early as 2016/10/09. The version of binutils imported from head on 2016/06/09 does not appear to have this leak.
[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832 --- Comment #9 from Paul Pluzhnikov --- Still broken on trunk @r231541. Closing on 2 years now.
[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832 --- Comment #11 from Paul Pluzhnikov --- (In reply to Markus Trippelsdorf from comment #10) > Patches are welcome. Yes, I know. As I lamented in comment #7, I don't know enough GCC internals to take this on.
[Bug target/67396] [4.9/5.0 regression] Performance regression compiling variadic function with many arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67396 --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Andrew Pinski from comment #2) Can you provide -ftime-report ? Sure: perl gen_bz18872.pl 2000 t.c gcc-svn-r227321/bin/gcc -c -O2 t.c -ftime-report Execution times (seconds) phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 1066 kB (19%) ggc phase parsing : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 1486 kB (27%) ggc phase opt and generate : 102.09 (100%) usr 0.01 (100%) sys 102.29 (100%) wall2997 kB (54%) ggc garbage collection : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc CFG verifier: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc df use-def / def-use chains: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc preprocessing : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 948 kB (17%) ggc lexical analysis: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc parser (global) : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 297 kB ( 5%) ggc tree STMT verifier : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc dominance computation : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc expand : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 484 kB ( 9%) ggc dead store elim1: 101.85 (100%) usr 0.01 (100%) sys 101.96 (100%) wall 171 kB ( 3%) ggc dead store elim2: 0.11 ( 0%) usr 0.00 ( 0%) sys 0.11 ( 0%) wall 171 kB ( 3%) ggc CSE 2 : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc integrated RA : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 24 kB ( 0%) ggc reload CSE regs : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 280 kB ( 5%) ggc thread pro- epilogue : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 1 kB ( 0%) ggc peephole 2 : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc scheduling 2: 0.06 ( 0%) usr 0.00 ( 0%) sys 0.08 ( 0%) wall 1558 kB (28%) ggc initialize rtl : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 12 kB ( 0%) ggc rest of compilation : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 2 kB ( 0%) ggc unaccounted todo: 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc verify RTL sharing : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc TOTAL : 102.10 0.01 102.31 5558 kB Extra diagnostic checks enabled; compiler may run slowly. Configure with --enable-checking=release to disable checks. perf report says: Samples: 409K of event 'cycles', Event count (approx.): 374080784459 32.25% cc1 cc1[.] find_base_term(rtx_def*) 27.15% cc1 cc1[.] get_addr(rtx_def*) [clone .part.39] 16.57% cc1 cc1[.] rtx_equal_for_memref_p(rtx_def const*, rtx_def const*) 11.37% cc1 cc1[.] memrefs_conflict_p(int, rtx_def*, int, rtx_def*, long) [clone .constprop.113] 5.76% cc1 cc1[.] addr_side_effect_eval(rtx_def*, int, int) [clone .constprop.114] 2.81% cc1 cc1[.] ix86_find_base_term(rtx_def*) 2.52% cc1 cc1[.] cselib_sp_based_value_p(cselib_val*) 1.11% cc1 cc1[.] cselib_have_permanent_equivalences() 0.13% cc1 cc1[.] record_store(rtx_def*, dse_bb_info_type*) ...
[Bug target/67396] [4.9/5.0 regression] Performance regression compiling variadic function with many arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67396 --- Comment #5 from Paul Pluzhnikov ppluzhnikov at google dot com --- please do before you report compile time regressions. Ok. Here are the new numbers from current trunk built with --enable-checking=release (nothing's changed that I can see; still very slow): for j in 500 1000 2000 3000; do perl ./gen_bz18872.pl $j t.c ; (time gcc-svn-r227326-rel/bin/gcc -c -O2 t.c) | grep user; done user0m1.488s user0m12.010s user1m40.353s user5m47.668s Here is the -ftime-report: perl ./gen_bz18872.pl 2000 t.c gcc-svn-r227326-rel/bin/gcc -c -O2 t.c -ftime-report Execution times (seconds) phase setup : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 1066 kB (19%) ggc phase parsing : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.02 ( 0%) wall 1486 kB (27%) ggc phase opt and generate : 100.30 (100%) usr 0.00 ( 0%) sys 100.43 (100%) wall2997 kB (54%) ggc trivially dead code : 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc df scan insns : 0.01 ( 0%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 0 kB ( 0%) ggc preprocessing : 0.02 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 948 kB (17%) ggc lexical analysis: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 ( 0%) wall 0 kB ( 0%) ggc dead store elim1: 100.17 (100%) usr 0.00 ( 0%) sys 100.29 (100%) wall 171 kB ( 3%) ggc dead store elim2: 0.10 ( 0%) usr 0.00 ( 0%) sys 0.10 ( 0%) wall 171 kB ( 3%) ggc scheduling 2: 0.02 ( 0%) usr 0.00 ( 0%) sys 0.03 ( 0%) wall 1558 kB (28%) ggc TOTAL : 100.32 0.00 100.45 5558 kB perf report: Samples: 406K of event 'cycles', Event count (approx.): 372444339282 32.97% cc1 cc1[.] find_base_term(rtx_def*) 25.58% cc1 cc1[.] get_addr(rtx_def*) [clone .part.33] 17.70% cc1 cc1[.] rtx_equal_for_memref_p(rtx_def const*, rtx_def const*) 11.33% cc1 cc1[.] memrefs_conflict_p(int, rtx_def*, int, rtx_def*, long) [clone .constprop.107] 5.79% cc1 cc1[.] addr_side_effect_eval(rtx_def*, int, int) [clone .constprop.108] 2.43% cc1 cc1[.] cselib_sp_based_value_p(cselib_val*) 2.34% cc1 cc1[.] ix86_find_base_term(rtx_def*) 1.41% cc1 cc1[.] cselib_have_permanent_equivalences() 0.14% cc1 cc1[.] record_store(rtx_def*, dse_bb_info_type*)
[Bug c/67396] [4.9/5.0 regression] Performance regression compiling variadic function with many arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67396 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||jh at suse dot cz --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- This is caused by r206947: 2014-01-22 Jan Hubicka j...@suse.cz + * config/i386/x86-tune.def (X86_TUNE_ACCUMULATE_OUTGOING_ARGS): + Enable for generic and recent AMD targets. + +2014-01-22 Jan Hubicka j...@suse.cz + * combine-stack-adj.c (combine_stack_adjustments_for_block): Remove ARG_SIZE note when adjustment was eliminated. Index: gcc/config/i386/x86-tune.def === --- gcc/config/i386/x86-tune.def(revision 206946) +++ gcc/config/i386/x86-tune.def(revision 206947) @@ -146,7 +146,7 @@ use of the frame pointer in 32bit mode. */ DEF_TUNE (X86_TUNE_ACCUMULATE_OUTGOING_ARGS, accumulate_outgoing_args, m_PPRO | m_P4_NOCONA | m_BONNELL | m_SILVERMONT | m_INTEL - | m_AMD_MULTIPLE | m_GENERIC) + | m_ATHLON_K8) /* X86_TUNE_PROLOGUE_USING_MOVE: Do not use push/pop in prologues that are considered on critical path. */ The patch appears to be backwards from what the commit message says though? $ time gcc-svn-r206948/bin/gcc -c -O2 t.c -mtune=k8 real0m1.411s user0m1.391s sys 0m0.019s $ time gcc-svn-r206948/bin/gcc -c -O2 t.c ^C real1m31.462s user0m0.000s sys 0m0.006s $ time gcc-svn-r206948/bin/gcc -c -O2 t.c -mtune=generic ^C real1m14.054s user0m0.000s sys 0m0.004s
[Bug c/67396] New: [4.9/5.0 regression] Performance regression compiling variadic function with many arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67396 Bug ID: 67396 Summary: [4.9/5.0 regression] Performance regression compiling variadic function with many arguments 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 Target Milestone: --- Created attachment 36270 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36270action=edit test generator script For https://sourceware.org/bugzilla/show_bug.cgi?id=18872, I need a test case that calls printf() with = 2700 arguments. GCC-4.9 and 5.0 (and current trunk) take excessively long to compile such test cases with optimization: $ perl gen_bz18872.pl 500 t.c time gcc-svn-r227321/bin/gcc -c -O2 t.c user0m1.506s $ perl gen_bz18872.pl 1000 t.c time gcc-svn-r227321/bin/gcc -c -O2 t.c user0m11.976s $ perl gen_bz18872.pl 2000 t.c gcc-svn-r227321/bin/gcc -c -O2 t.c user1m40.911s $ perl gen_bz18872.pl 4000 t.c gcc-svn-r227321/bin/gcc -c -O2 t.c user14m0.767s ### Yikes! For comparison, gcc-4.8 (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4 compiles the 4000 argument case in 1.3s. The problem is already present in r220312 (the oldest build I have).
[Bug c++/61022] [C++11] Bogus error: parameter packs not expanded with '...'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61022 --- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com --- Still fails with trunk @r222386
[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832 --- Comment #7 from Paul Pluzhnikov ppluzhnikov at google dot com --- Still broken on trunk @r221169. Leaving known ICEs for = 1 year untouched seems... suboptimal. (Sorry I don't know enough GCC internals to take this on.)
[Bug target/65263] [5 Regression] ICE (error: unrecognizable insn / in insn_min_length, at config/rs6000/rs6000.md) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65263 --- Comment #10 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Jan Hubicka from comment #9) Paul, I fixed similar bug yesterday, so please check if it works now I just built at current SVN trunk (r221126). Filed PR 65287
[Bug target/65263] [5 Regression] ICE (error: unrecognizable insn / in insn_min_length, at config/rs6000/rs6000.md) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65263 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #8 from Paul Pluzhnikov ppluzhnikov at google dot com --- r221040 is also possibly causing: ../sysdeps/gnu/siglist.c:77:1: internal compiler error: in address_matters_p, at symtab.c:1908 when building trunk GLIBC (seen with GCC @r221125; same source builds with GCC @r220312).
[Bug c/65287] New: Current trunk ICE in address_matters_p, at symtab.c:1908
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65287 Bug ID: 65287 Summary: Current trunk ICE in address_matters_p, at symtab.c:1908 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 Created attachment 34927 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34927action=edit test case Continued from PR 65263 r221040 is also possibly causing: ../sysdeps/gnu/siglist.c:77:1: internal compiler error: in address_matters_p, at symtab.c:1908 when building trunk GLIBC (seen with GCC @r221125; same source builds with GCC @r220312). ../sysdeps/gnu/siglist.c:77:1: internal compiler error: in address_matters_p, at symtab.c:1908 versioned_symbol (libc, __new_sys_sigabbrev, sys_sigabbrev, GLIBC_2_1); ^ 0x747118 symtab_node::address_matters_p() ../../gcc/symtab.c:1908 0x10e1dcb ipa_icf::sem_variable::merge(ipa_icf::sem_item*) ../../gcc/ipa-icf.c:1723 0x10e4b21 ipa_icf::sem_item_optimizer::merge_classes(unsigned int) ../../gcc/ipa-icf.c:2955 0x10ed8c4 ipa_icf::sem_item_optimizer::execute() ../../gcc/ipa-icf.c:2217 0x10ef521 ipa_icf_driver ../../gcc/ipa-icf.c:3034 0x10ef521 ipa_icf::pass_ipa_icf::execute(function*) ../../gcc/ipa-icf.c:3081 Please submit a full bug report, Reproduces with: gcc-svn-r221125/bin/gcc -c -O2 /tmp/t.i
[Bug c/65287] Current trunk ICE in address_matters_p, at symtab.c:1908
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65287
--- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Created attachment 34928
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34928action=edit
c-reduce'd test case
A much shorter test:
const int __new_sys_siglist[] = {};
extern __typeof(__new_sys_siglist) _new_sys_siglist
__attribute__((alias(__new_sys_siglist)));
extern __typeof(__new_sys_siglist) _sys_siglist
__attribute__((alias(__new_sys_siglist)));
[Bug rtl-optimization/64557] get_addr in true_dependence_1 cannot handle VALUE inside an expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/18933287
[Bug c++/60978] -Wenum-compare warns too eagerly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978
--- Comment #9 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Jason Merrill from comment #8)
You shouldn't get the warning about IPPROTO_ICMP vs IPPROTO_ICMPV66, as they
are members of the same anonymous enum.
They are?
In glibc-2.19, include/netinet/in.h:
/* Standard well-defined IP protocols. */
enum
{
IPPROTO_IP = 0, /* Dummy protocol for TCP. */
#define IPPROTO_IPIPPROTO_IP
IPPROTO_ICMP = 1, /* Internet Control Message Protocol. */
#define IPPROTO_ICMPIPPROTO_ICMP
...
};
/* If __USE_KERNEL_IPV6_DEFS is defined then the user has included the kernel
network headers first and we should use those ABI-identical definitions
instead of our own. */
#ifndef __USE_KERNEL_IPV6_DEFS
enum
{
IPPROTO_HOPOPTS = 0, /* IPv6 Hop-by-Hop options. */
...
IPPROTO_ICMPV6 = 58, /* ICMPv6. */
...
};
Looks like different anonymous enums to me.
[Bug c++/60978] -Wenum-compare warns too eagerly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978 --- Comment #11 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Jason Merrill from comment #10) Interesting, in glibc 2.18 (at least in glibc-headers-2.18-16.fc20.x86_64) they are in the same enum. The in.h is actually part of kernel, not glibc itself. We used linux-3.12.6 make headers_install to get include/netinet/in.h.
[Bug c++/61022] [C++11] Bogus error: parameter packs not expanded with '...'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61022 --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Still fails with trunk @r216948
[Bug c++/63578] New: ICE In layout_type, at stor-layout.c:2398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63578 Bug ID: 63578 Summary: ICE In layout_type, at stor-layout.c:2398 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/18024040 Test: int *b; auto __attribute__ ((may_alias)) a = b; // replace auto with int* to fix Using trunk @r216408: r216408/bin/g++ -c -std=c++11 t.ii t.ii:2:34: internal compiler error: in layout_type, at stor-layout.c:2398 auto __attribute__ ((may_alias)) a = b; ^ 0xbef8f3 layout_type(tree_node*) ../../gcc/stor-layout.c:2398 0xe36955 type_hash_canon(unsigned int, tree_node*) ../../gcc/tree.c:6821 0xe5344c build_type_attribute_qual_variant(tree_node*, tree_node*, int) ../../gcc/tree.c:4668 0x7a4966 decl_attributes(tree_node**, tree_node*, int) ../../gcc/attribs.c:621 0x670604 cplus_decl_attributes(tree_node**, tree_node*, int) ../../gcc/cp/decl2.c:1470 0x5d1162 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int, tree_node*, tree_node*, tree_node**) ../../gcc/cp/decl.c:4630 0x6b9a2a cp_parser_init_declarator ../../gcc/cp/parser.c:17060 0x6bb559 cp_parser_simple_declaration ../../gcc/cp/parser.c:11538 0x69b0d3 cp_parser_block_declaration ../../gcc/cp/parser.c:11419 0x6c6df9 cp_parser_declaration ../../gcc/cp/parser.c:11316 0x6c5a3a cp_parser_declaration_seq_opt ../../gcc/cp/parser.c:11202 0x6c72e2 cp_parser_translation_unit ../../gcc/cp/parser.c:4090 0x6c72e2 c_parse_file() ../../gcc/cp/parser.c:32207 0x7f1942 c_common_parse_file() ../../gcc/c-family/c-opts.c:1046 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Also broken in gcc-4.8
[Bug c++/63540] Erroneous 'Derived' declares a move constructor or move assignment operator in error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63540 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/17785687
[Bug c++/63149] wrong auto deduction from braced-init-list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63149 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/17312516
[Bug c++/62310] fails to consider default initializers (NSDMIs) when checking inheriting constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62310 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/17333074
[Bug c/25509] can't disable __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25509 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #28 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/16983603. I wouldn't call this bug fixed. I have just found ~30 bugs in our code, where someone wrote: vectorint v; ... v.empty(); // v.clear() was intended! No problem, I'll just add warn_unused_result to vector::empty(), right? Well, that did expose the 30 bugs above, but unfortunately I can't do that permanently, because it also exposed this false positive: assert(v.empty()); where assert in NDEBUG mode expanded into static_castvoid(v.empty()); and triggered the warning :-( P.S. Some of the bugs I found were in parts of the code imported from open-source projects, so it's not a problem that is specific to just Google. If the assert problem could be addressed, adding warn_unused_result to trunk libstdc++ would benefit everyone.
[Bug libstdc++/61947] [4.8/4.9/4.10 Regression] Ambiguous calls when constructing std::tuple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61947 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/16644819
[Bug c++/61924] New: [C++11] ICE in instantiate_template_1, at cp/pt.c:15618
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61924
Bug ID: 61924
Summary: [C++11] ICE in instantiate_template_1, at
cp/pt.c:15618
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/16582830
Gcc 4.8, 4.9 and current trunk @r213084 are affected.
// --- cut ---
struct function
{
template typename _Functor function (_Functor);
};
template typename struct RetryingRpc
{
template typename StubType RetryingRpc (StubType, function =[]{});
};
void fn()
{
RetryingRpcint rpc(0, []{});
};
// --- cut ---
This is accepted by Clang, ICEs with current trunk:
gcc-svn-r213084/bin/g++ -c -std=c++11 t.ii
t.ii: In substitution of ‘templateclass StubType RetryingRpc
template-parameter-1-1 ::RetryingRpc(StubType, function) [with StubType =
int]’:
t.ii:13:31: required from here
t.ii:13:31: internal compiler error: in instantiate_template_1, at
cp/pt.c:15618
RetryingRpcint rpc(0, []{});
^
0x5c094b instantiate_template_1
../../gcc/cp/pt.c:15618
0x5c094b instantiate_template(tree_node*, tree_node*, int)
../../gcc/cp/pt.c:15730
0x5ef8cb fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/cp/pt.c:16079
0x55f659 add_template_candidate_real
../../gcc/cp/call.c:3025
0x5600dc add_template_candidate
../../gcc/cp/call.c:3122
0x5600dc add_candidates
../../gcc/cp/call.c:5253
0x560956 build_new_method_call_1
../../gcc/cp/call.c:7944
0x560956 build_new_method_call(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, tree_node*, int, tree_node**, int)
../../gcc/cp/call.c:8140
0x561f29 build_special_member_call(tree_node*, tree_node*, vectree_node*,
va_gc, vl_embed**, tree_node*, int, int)
../../gcc/cp/call.c:7684
0x6b7299 expand_default_init
../../gcc/cp/init.c:1707
0x6b7299 expand_aggr_init_1
../../gcc/cp/init.c:1808
0x6b9f5c build_aggr_init(tree_node*, tree_node*, int, int)
../../gcc/cp/init.c:1560
0x574b5c build_aggr_init_full_exprs
../../gcc/cp/decl.c:5645
0x574b5c check_initializer
../../gcc/cp/decl.c:5789
0x58544c cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../gcc/cp/decl.c:6461
0x676995 cp_parser_init_declarator
../../gcc/cp/parser.c:17058
0x6780d5 cp_parser_simple_declaration
../../gcc/cp/parser.c:11421
0x65bcf3 cp_parser_block_declaration
../../gcc/cp/parser.c:11302
0x65ce31 cp_parser_declaration_statement
../../gcc/cp/parser.c:10949
0x65d51b cp_parser_statement
../../gcc/cp/parser.c:9664
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
[Bug c++/44122] Confusing error: cannot convert 'T*' to 'T*' (when T are different scopes)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44122
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #5 from Paul Pluzhnikov ppluzhnikov at google dot com ---
GCC output @r212875:
svn-r212875/bin/g++ -c t.cc
t.cc: In function ‘int bar()’:
t.cc:8:18: error: cannot convert ‘Py_ssize_t* {aka int*}’ to ‘Py_ssize_t* {aka
long int*}’ for argument ‘1’ to ‘int foo(Py_ssize_t*)’
return foo(pos);
^
[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832 --- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com --- Still broken @r212875
[Bug c++/59815] Apparently bogus error: 'Outer' is already declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59815 --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- Still broken @r212875
[Bug middle-end/59812] Missing aggressive loop optimization warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59812 --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- Reconfirmed @r212875
[Bug c++/61833] [4.9] ICE in fold_comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61833 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com --- I confirmed that both the reduced case and the original no longer ICE on gcc-4_9-branch @r212773.
[Bug c++/61833] New: [4.9] ICE in fold_comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61833 Bug ID: 61833 Summary: [4.9] ICE in fold_comparison 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 Created attachment 33134 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33134action=edit test case Google ref: b/16030670 Originally reported against gcc-4.8. Attached test case causes gcc-4_9-branch (r212536) to ICE like this (but only with -O2): gcc-svn-4_9-r212536/bin/g++ -c -std=c++11 t.ii -O2 t.ii: In function ‘void ToSpec()’: t.ii:158:1: internal compiler error: Segmentation fault ToSpec () ^ 0xb947ff crash_signal ../../gcc/toplev.c:337 0x952096 fold_comparison ../../gcc/fold-const.c:9074 0x95b8a7 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) ../../gcc/fold-const.c:12953 0xbca30d cleanup_control_expr_graph ../../gcc/tree-cfgcleanup.c:112 0xbca30d cleanup_control_flow_bb ../../gcc/tree-cfgcleanup.c:187 0xbca30d cleanup_tree_cfg_bb ../../gcc/tree-cfgcleanup.c:630 0xbcbd48 cleanup_tree_cfg_1 ../../gcc/tree-cfgcleanup.c:675 0xbcbd48 cleanup_tree_cfg_noloop ../../gcc/tree-cfgcleanup.c:731 0xbcbd48 cleanup_tree_cfg() ../../gcc/tree-cfgcleanup.c:786 0xaea194 execute_function_todo ../../gcc/passes.c:1811 0xaeaa83 execute_todo ../../gcc/passes.c:1887 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. Trunk rejects the reduced test case with definition of std::initializer_list does not match #include initializer_list due to fixes for PR61723. Trunk @r212277 does not ICE.
[Bug c++/61723] [C++11] ICE in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723 --- Comment #8 from Paul Pluzhnikov ppluzhnikov at google dot com --- Filed PR61833
[Bug c++/61723] [C++11] ICE in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723 --- Comment #5 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Paolo Carlini from comment #1) I find this testcase rather weird It's the result of creduce over a preprocessed original. std::initializer_list isn't a random user type In the non-reduced test (which is 15MB in size), it's the full type. OK, now GCC will reject the definition of std::initializer_list rather than ICE. I'll check whether original test still ICEs, and re-reduce if it still does.
[Bug c++/61723] [C++11] ICE in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723 --- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com --- It turns out that the original unreduced test case does not error on trunk @r212277; it only ICEs on gcc-4.8 and gcc-4.9 branches. But once I creduced it using 4.9, the reduced test also ICEd on trunk. I have just verified that the latest 4.9 @r212536 crashes like so on non-reduced test: gcc-svn-4_9-r212536/bin/g++ -c -std=c++11 t.ii -O2 t.cc: In function ‘’: t.cc:22:24: internal compiler error: Segmentation fault 0xb947ff crash_signal ../../gcc/toplev.c:337 0x952096 fold_comparison ../../gcc/fold-const.c:9074 0x95be35 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) ../../gcc/fold-const.c:13563 0xbca30d cleanup_control_expr_graph ../../gcc/tree-cfgcleanup.c:112 0xbca30d cleanup_control_flow_bb ../../gcc/tree-cfgcleanup.c:187 0xbca30d cleanup_tree_cfg_bb ../../gcc/tree-cfgcleanup.c:630 0xbcbd48 cleanup_tree_cfg_1 ../../gcc/tree-cfgcleanup.c:675 0xbcbd48 cleanup_tree_cfg_noloop ../../gcc/tree-cfgcleanup.c:731 0xbcbd48 cleanup_tree_cfg() ../../gcc/tree-cfgcleanup.c:786 0xaea194 execute_function_todo ../../gcc/passes.c:1811 0xaeaa83 execute_todo ../../gcc/passes.c:1887 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. This appears to be a different ICE. Should I reduce it?
[Bug c++/61723] New: [C++11] ICE in contains_struct_check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61723
Bug ID: 61723
Summary: [C++11] ICE in contains_struct_check
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/16030670.
AFAICT, this is broken in all of 4.7 / 4.8 / 4.9 / 4.10.
Accepted by Clang without warnings.
gcc-svn-r212277/bin/g++ -c -std=c++11 t.cc
t.cc: In function ‘void fn1()’:
t.cc:29:14: internal compiler error: Segmentation fault
spec.dim = { };
^
0xb8527f crash_signal
../../gcc/toplev.c:337
0x557b81 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/tree.h:2844
0x557b81 convert_like_real
../../gcc/cp/call.c:6257
0x554eab build_over_call
../../gcc/cp/call.c:7162
0x55800b convert_like_real
../../gcc/cp/call.c:6160
0x55799b convert_like_real
../../gcc/cp/call.c:6290
0x554eab build_over_call
../../gcc/cp/call.c:7162
0x56785c build_new_op_1
../../gcc/cp/call.c:5513
0x567c4e build_new_op(unsigned int, tree_code, int, tree_node*, tree_node*,
tree_node*, tree_node**, int)
../../gcc/cp/call.c:5674
0x6a6aeb cp_build_modify_expr(tree_node*, tree_code, tree_node*, int)
../../gcc/cp/typeck.c:7399
0x669632 cp_parser_assignment_expression
../../gcc/cp/parser.c:8216
0x66b8a3 cp_parser_expression
../../gcc/cp/parser.c:8342
0x66c0cc cp_parser_expression
../../gcc/cp/parser.c:8381
0x66c0cc cp_parser_expression_statement
../../gcc/cp/parser.c:9720
0x660e98 cp_parser_statement
../../gcc/cp/parser.c:9571
0x661ca9 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:9843
0x661e16 cp_parser_compound_statement
../../gcc/cp/parser.c:9797
0x67319b cp_parser_function_body
../../gcc/cp/parser.c:18872
0x67319b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:18908
0x679883 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:23044
Please submit a full bug report,
with preprocessed source if appropriate.
gcc-svn-r212277/bin/g++ -c -std=c++11 t.cc -DBUG1
t.cc: In function ‘void fn1()’:
t.cc:26:1: error: non-trivial conversion at assignment
fn1 ()
^
int
const int[0:18446744073709551615] *
D.2173._M_len = ._0;
t.cc:26:1: internal compiler error: verify_gimple failed
0xbb49ff verify_gimple_in_seq(gimple_statement_base*)
../../gcc/tree-cfg.c:4665
0x9cb6c1 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:8848
0x9cba26 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:8933
0x84be17 analyze_function
../../gcc/cgraphunit.c:650
0x84d01f analyze_functions
../../gcc/cgraphunit.c:1028
0x84e8e5 finalize_compilation_unit()
../../gcc/cgraphunit.c:2331
0x63b07e cp_write_global_declarations()
../../gcc/cp/decl2.c:4652
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
// -- cut ---
namespace std {
template class struct initializer_list
{
#if BUG1
int _M_len;
#endif
const int *begin ();
const int *end ();
};
}
struct J
{
J (const int );
template typename InputIterator J (InputIterator, InputIterator);
J (std::initializer_list int p1):J (p1.begin (), p1.end ()) { }
};
struct L
{
L ():dim (0) { }
J dim;
};
void
fn1 ()
{
L spec;
spec.dim = { };
}
// --- cut ---
[Bug c++/58930] [C++11] Bogus error: converting to ... from initializer list would use explicit constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58930 --- Comment #5 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Paolo Carlini from comment #4) Fixed for 4.10.0. Can this be back-ported to gcc-4_9-branch?
[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832 --- Comment #5 from Paul Pluzhnikov ppluzhnikov at google dot com --- Still broken on trunk @r211990. Any chance someone can look at this?
[Bug c++/61614] New: [4.9/4.10 Regression] Bogus error: taking address of temporary array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61614
Bug ID: 61614
Summary: [4.9/4.10 Regression] Bogus error: taking address of
temporary array
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/15883782
This broke on trunk sometime after r200178, is broken currently (r211990), and
also on gcc-4_9-branch.
// --- cut ---
int Fn (...);
void
Test ()
{
int j = Fn ((const int[]) { 0 });// OK
unsigned long sz = sizeof Fn ((const int[]) { 0 }); // Error
}
// --- cut ---
gcc-svn-r211990/bin/g++ -c t.ii
t.ii: In function 'void Test()':
t.ii:7:52: error: taking address of temporary array
unsigned long sz = sizeof Fn ((const int[]) { 0 }); // Error
^
[Bug c++/61581] New: [C++11] Bogus error: uninitialized const member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61581
Bug ID: 61581
Summary: [C++11] Bogus error: uninitialized const member
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/15789654
Fails with current trunk, and all older versions I've tried.
g++ -c t.cc -std=c++11
t.cc: In function 'void Bar()':
t.cc:9:11: error: uninitialized const member 'Foo::b'
Fn( {1} );
^
/// -- cut ---
struct Foo {
long a;
const long b;
};
void Fn(const Foo);
void Bar() {
Fn( {1} );
}
/// -- cut ---
Removing 'const' and examining assembly shows that GCC *does* initialize 'b' to
0 (as it should).
[Bug c++/60265] [C++11] using-declaration of enumerator fails if fully qualified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60265 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- Can this be backported to 4_9-branch? Google ref: b/15617537
[Bug c++/61575] New: [4.9 Regression] Bogus invalid initialization of reference of type 'const D' from expression of type 'brace-enclosed initializer list'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61575
Bug ID: 61575
Summary: [4.9 Regression] Bogus invalid initialization of
reference of type 'const D' from expression of type
'brace-enclosed initializer list'
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/15094102
The following test compiles with gcc-4.8 and trunk, fails with current
gcc-4_9-branch:
/// -- cut ---
struct D
{
const int x;
const int y;
};
int Create (const D );
void fn1 ()
{
Create ( { {}, {} });
}
/// -- cut ---
gcc-svn-4_9-r211828/bin/gcc -c -std=c++11 t.ii
gcc-svn-4_9-r211175/bin/gcc -c -std=c++11 t.ii
t.ii: In function 'void fn1()':
t.ii:10:22: error: invalid initialization of reference of type 'const D' from
expression of type 'brace-enclosed initializer list'
Create ( { {}, {} });
^
t.ii:6:5: note: in passing argument 1 of 'int Create(const D)'
int Create (const D );
^
The source is accepted by Clang, and trunk (@r211826). It was rejected by
trunk in the past:
OK gcc-svn-r195189/bin/gcc
OK gcc-svn-r197259/bin/gcc
OK gcc-svn-r198246/bin/gcc
OK gcc-svn-r198956/bin/gcc
OK gcc-svn-r199779/bin/gcc
OK gcc-svn-r199793/bin/gcc
OK gcc-svn-r199956/bin/gcc
OK gcc-svn-r200178/bin/gcc
... broke somewhere here
KO gcc-svn-r210292/bin/gcc
KO gcc-svn-r210629/bin/gcc
... refixed somewhere here
OK gcc-svn-r211159/bin/gcc
OK gcc-svn-r211286/bin/gcc
OK gcc-svn-r211479/bin/gcc
OK gcc-svn-r211743/bin/gcc
OK gcc-svn-r211826/bin/gcc
[Bug c++/61575] [4.9 Regression] Bogus invalid initialization of reference of type 'const D' from expression of type 'brace-enclosed initializer list'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61575 --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Sorry, cut/paste error. Both gcc-svn-4_9-r211828/bin/gcc gcc-svn-4_9-r211175/bin/gcc fails the same way.
[Bug c++/61566] New: [4.9/4.10 Regression] ICE in write_unscoped_name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61566
Bug ID: 61566
Summary: [4.9/4.10 Regression] ICE in write_unscoped_name
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
Created attachment 32977
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32977action=edit
test case
Google ref: b/15734838
Test case compiles fine with Clang and current gcc-4_8-branch (@r211826).
Broken on trunk (and gcc-4_9) since not later than r195189.
Using current trunk @r211826:
gcc-svn-install/bin/g++ -c -std=c++11 t.cc
t.cc: In instantiation of 'std::function_Res(_ArgTypes
...)::function(_Functor) [with _Functor = C::lambda()H, int;
template-parameter-2-2 = int; _Res = std::A; _ArgTypes = {}]':
t.cc:24:7: internal compiler error: in write_unscoped_name, at cp/mangle.c:881
function (_Functor);
^
0x727aa1 write_unscoped_name
../../gcc/cp/mangle.c:879
0x72b205 write_unscoped_template_name
../../gcc/cp/mangle.c:897
0x72b205 write_name
../../gcc/cp/mangle.c:810
0x72b0e0 write_local_name
../../gcc/cp/mangle.c:1808
0x72b0e0 write_name
../../gcc/cp/mangle.c:842
0x72bcbe write_class_enum_type
../../gcc/cp/mangle.c:2496
0x72bcbe write_type
../../gcc/cp/mangle.c:1954
0x72acc8 write_template_args
../../gcc/cp/mangle.c:2525
0x72f4ed write_nested_name
../../gcc/cp/mangle.c:941
0x72afa7 write_name
../../gcc/cp/mangle.c:854
0x72fe3b write_encoding
../../gcc/cp/mangle.c:704
0x730609 mangle_decl_string
../../gcc/cp/mangle.c:3383
0x730857 get_mangled_id
../../gcc/cp/mangle.c:3405
0x730857 mangle_decl(tree_node*)
../../gcc/cp/mangle.c:3428
0xdb03f0 decl_assembler_name(tree_node*)
../../gcc/tree.c:603
0x83f0d4 insert_to_assembler_name_hash
../../gcc/symtab.c:187
0x83f231 symtab_initialize_asm_name_hash()
../../gcc/symtab.c:366
0x84ea54 analyze_functions
../../gcc/cgraphunit.c:1135
0x84ffa5 finalize_compilation_unit()
../../gcc/cgraphunit.c:2333
0x63e4ae cp_write_global_declarations()
../../gcc/cp/decl2.c:4647
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug tree-optimization/61493] [4.10 Regression] Bug exposed by speculative devirtualizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61493 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com --- Also broken in 4.9
[Bug c++/58704] [c++11] ICE initializing array member of template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58704 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com --- We've hit this in gcc-4.8 and 4.9 as well. Backport? Google ref: b/15616365
[Bug tree-optimization/61289] [4.9 Regression] Bad jump threading generates infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61289 --- Comment #4 from Paul Pluzhnikov ppluzhnikov at google dot com --- Back-port to gcc-4_9-branch? Thanks,
[Bug middle-end/61456] Bogus may be used uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61456 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/15089262 error: ‘fp.int* (Funcs::* const)()::__delta’ is used uninitialized ... Note that there is no '__delta' in the original source, so the error message is exceedingly confusing to the end user, in addition to being bogus.
[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832 --- Comment #4 from Paul Pluzhnikov ppluzhnikov at google dot com --- Still reproduces on current trunk @r211286
[Bug c++/61445] New: [C++11][4.10 Regression] ice in instantiate_decl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61445
Bug ID: 61445
Summary: [C++11][4.10 Regression] ice in instantiate_decl
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 be a recent regression in trunk.
Source reduced from llvm/tools/clang/tools/clang-check/ClangCheck.cpp
Using trunk @r211286:
gcc-svn-r211286/bin/g++ -c t1.ii -std=c++11
t1.ii: In instantiation of ‘void newFrontendActionFactory(FactoryT*,
int*)::A::m_fn1() [with FactoryT = int]’:
t1.ii:18:5: required from ‘void newFrontendActionFactory(FactoryT*, int*)
[with FactoryT = int]’
t1.ii:19:33: required from here
t1.ii:11:13: internal compiler error: in instantiate_decl, at cp/pt.c:19753
B (0, 0);
^
0x5c6d0f instantiate_decl(tree_node*, int, bool)
../../gcc/cp/pt.c:19752
0x63cda3 mark_used(tree_node*, int)
../../gcc/cp/decl2.c:5016
0x557f73 build_over_call
../../gcc/cp/call.c:7335
0x563880 build_new_method_call_1
../../gcc/cp/call.c:8047
0x563880 build_new_method_call(tree_node*, tree_node*, vectree_node*, va_gc,
vl_embed**, tree_node*, int, tree_node**, int)
../../gcc/cp/call.c:8117
0x564959 build_special_member_call(tree_node*, tree_node*, vectree_node*,
va_gc, vl_embed**, tree_node*, int, int)
../../gcc/cp/call.c:7661
0x607df6 build_functional_cast(tree_node*, tree_node*, int)
../../gcc/cp/typeck2.c:1935
0x5bbf86 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:14415
0x5ca963 tsubst_expr
../../gcc/cp/pt.c:14133
0x5cad61 tsubst_expr
../../gcc/cp/pt.c:13559
0x5caf03 tsubst_expr
../../gcc/cp/pt.c:13731
0x5c8503 instantiate_decl(tree_node*, int, bool)
../../gcc/cp/pt.c:20043
0x5caa2b tsubst_expr
../../gcc/cp/pt.c:13872
0x5ca273 tsubst_expr
../../gcc/cp/pt.c:13545
0x5caf03 tsubst_expr
../../gcc/cp/pt.c:13731
0x5c8503 instantiate_decl(tree_node*, int, bool)
../../gcc/cp/pt.c:20043
0x601387 instantiate_pending_templates(int)
../../gcc/cp/pt.c:20159
0x63e7ef cp_write_global_declarations()
../../gcc/cp/decl2.c:4348
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
The crash does not reproduce without -std=c++11, nor using trunk build
@r210629.
/// -- cut ---
template typename FactoryT void newFrontendActionFactory (FactoryT *, int *
= 0);
int a;
template typename FactoryT
void newFrontendActionFactory (FactoryT *, int *)
{
class A
{
void m_fn1 ()
{
B (0, 0);
}
class B
{
public:
B (FactoryT, int);
};
};
newFrontendActionFactory (a);
}
[Bug libstdc++/61426] New: [C++11] std::deque requires more from allocator than the standard provides.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61426
Bug ID: 61426
Summary: [C++11] std::deque requires more from allocator than
the standard provides.
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/15420505
Section 23.3.3.1 of C++11 shows the following typedef members of deque,
among others:
typedef typename allocator_traitsAllocator::pointer pointer;
typedef typename allocator_traitsAllocator::const_pointer const_pointer;
Table 28 in section 17.6.3.5 shows that the `pointer` and `const_pointer`
members of allocator_traits have defaults, and therefore by the text in
17.6.3.5.2 the allocator type is not required to define these.
We should be able to use a custom allocator type with deque without defining
these. For what it's worth, cppreference.com agrees; it calls them optional
and doesn't include them in its minimal example (grep SimpleAllocator):
http://en.cppreference.com/w/cpp/concept/Allocator
Above allocator works for std::vector and std::map, but not std::deque
(using trunk GCC @r211286).
Test case:
#include cstddef
template class Tp
struct SimpleAllocator {
typedef Tp value_type;
SimpleAllocator(/*ctor args*/);
template class T SimpleAllocator(const SimpleAllocatorT other);
Tp* allocate(std::size_t n);
void deallocate(Tp* p, std::size_t n);
#ifdef REBIND
templatetypename U
struct rebind {
typedef SimpleAllocatorU other;
};
#endif
};
template class T, class U
bool operator==(const SimpleAllocatorT, const SimpleAllocatorU);
template class T, class U
bool operator!=(const SimpleAllocatorT, const SimpleAllocatorU);
#include deque
typedef std::dequeint, SimpleAllocatorint IntDeque;
std::size_t foo(IntDeque d)
{
d.push_back(1);
d.pop_front();
return d.max_size();
}
/gcc-svn-r211286/bin/g++ -c t.cc -DDEQUE -std=c++11
In file included from /gcc-svn-r211286/include/c++/4.10.0/deque:64:0,
from t.cc:24:
/gcc-svn-r211286/include/c++/4.10.0/bits/stl_deque.h: In instantiation of
'class std::_Deque_baseint, SimpleAllocatorint ':
/gcc-svn-r211286/include/c++/4.10.0/bits/stl_deque.h:735:11: required from
'class std::dequeint, SimpleAllocatorint '
t.cc:29:4: required from here
/gcc-svn-r211286/include/c++/4.10.0/bits/stl_deque.h:490:61: error: no class
template named 'rebind' in 'struct SimpleAllocatorint'
typedef typename _Alloc::template rebind_Tp*::other _Map_alloc_type;
^
... many more ...
In addition to 'rebind', 'construct' and 'destroy', std::deque currently
also requires 'pointer', 'const_pointer', 'reference', 'const_reference'
and 'max_size', as can be seen by building with:
/gcc-svn-r211286/bin/g++ -c t.cc -DDEQUE -std=c++11 -DREBIND
[Bug tree-optimization/61289] Bad jump threading generates infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61289 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/15146357
[Bug c++/57063] static_cast from data member to rvalue reference sometimes wrongfully produces lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57063 --- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/15091778
[Bug c++/61242] New: [4.9/4.10 Regression] Bogus no matching function for call to ‘Foo::Create(brace-enclosed initializer list)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61242
Bug ID: 61242
Summary: [4.9/4.10 Regression] Bogus no matching function for
call to ‘Foo::Create(brace-enclosed initializer
list)
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 worked as recently as r200178, is broken in at least r210292 and later.
struct Foo
{
struct A
{
const int container;
const int args;
};
static void Create (const A );
};
int main ()
{
Foo::Create ({{}, {}});
}
g++ -std=c++11 -c t.cc
t.cc: In function 'int main()':
t.cc:13:24: error: no matching function for call to
'Foo::Create(brace-enclosed initializer list)'
Foo::Create ({{}, {}});
^
t.cc:13:24: note: candidate is:
t.cc:8:15: note: static void Foo::Create(const Foo::A)
static void Create (const A );
^
t.cc:8:15: note: no known conversion for argument 1 from 'brace-enclosed
initializer list' to 'const Foo::A'
Compiles with Clang and gcc-4.8.
Google ref: b/15094102
[Bug c++/61242] [4.9/4.10 Regression] Bogus no matching function for call to ‘Foo::Create(brace-enclosed initializer list)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61242 --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Forgot to mention: moving struct A and Create out of Foo and into global scope fixes the problem.
[Bug libstdc++/60970] Support std::hash with enum types (LWG 2148)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60970 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/8985947
[Bug tree-optimization/61009] [4.9 Regression] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 --- Comment #14 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Teresa Johnson from comment #13) Thanks for the fix! Indeed. Confirming that it does indeed fix the application issues we hit. I will add that we've had at least two separate miscompile instances due to this bug, resulting in several thousand of our unit test failing. Back-porting this to gcc-4_9-branch should be a relatively high priority.
[Bug c++/61134] New: [4.7/4.8/4.9/4.10 Regression][C++11] bogus no matching function for call...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61134
Bug ID: 61134
Summary: [4.7/4.8/4.9/4.10 Regression][C++11] bogus no
matching function for call...
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/14657431
The test case compiles with Clang and gcc-4.6, fails with -DBUG on all later
versions including current trunk (r210292):
g++ -c -std=gnu++11 t.cc echo OK g++ -c -std=gnu++11 t.cc -DBUG
OK
t.cc: In function 'void Fn()':
t.cc:22:55: error: no matching function for call to 'CreateMetric(const char
[5], const char [4], Base)'
CreateMetricint, const char*(abcd, def, Base());
^
t.cc:22:55: note: candidate is:
t.cc:15:6: note: templateclass VT, class ... Fields void CreateMetric(const
char*, typename FixedFields::name ..., const Base)
void CreateMetric(const char* name,
^
t.cc:15:6: note: template argument deduction/substitution failed:
t.cc:22:55: note: cannot convert 'def' (type 'const char [4]') to type
'const Base'
CreateMetricint, const char*(abcd, def, Base());
^
// --- cut ---
struct Base { };
template typename
struct Fixed {
typedef const char* name;
};
#if BUG
template typename VT, typename... Fields
void New(const char* name,
typename FixedFields::name... field_names);
#endif
template typename VT, typename... Fields
void CreateMetric(const char* name,
typename FixedFields::name... field_names,
const Base) { }
void Fn()
{
CreateMetricint, const char*(abcd, def, Base());
}
// --- cut ---
Note: The 'New()' function is not referenced outside the #ifdef block.
It's mere presense triggers the bug.
[Bug libstdc++/61023] set/map move assignment doesn't move (or copy) the comparator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61023
Paul Pluzhnikov ppluzhnikov at google dot com changed:
What|Removed |Added
CC||ppluzhnikov at google dot com
--- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com ---
Created attachment 32750
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32750action=edit
test case for move assignment operator
Just discovered this in Google code as well. Ref b/14590795
Move assign operator is broken the same way:
for no_rvalue in 1 0; do
for test in TEST_{,MULTI}{SET,MAP}; do
echo -e $no_rvalue $test \c; g++ -std=c++11 set.cc -D$test -g
-DNO_RVALUE=$no_rvalue ./a.out /dev/null
echo OK
done
done
1 TEST_SET OK
1 TEST_MAP OK
1 TEST_MULTISET OK
1 TEST_MULTIMAP OK
0 TEST_SET Aborted (core dumped)
0 TEST_MAP Aborted (core dumped)
0 TEST_MULTISET Aborted (core dumped)
0 TEST_MULTIMAP Aborted (core dumped)
Note: this is a 4.9/4.10 regression -- 4.8.3 works correctly.
[Bug c++/59832] [c++11] ICE in reshape_init_class with initializer list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59832 --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- Still reproduces on current trunk at r210049
[Bug c++/61020] New: [4.9/4.10 Regression] typeid(typeid(X)) produces 'ud2'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61020
Bug ID: 61020
Summary: [4.9/4.10 Regression] typeid(typeid(X)) produces 'ud2'
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
The test case:
#include typeinfo
struct Base {
virtual ~Base() { }
};
struct Derived : public Base {
};
int compare(const Base base)
{
return typeid(base) == typeid(typeid(Derived));
}
int main()
{
Base base;
Derived derived;
if (compare(base)) return 1;
if (compare(derived)) return 2;
return 0;
}
Using trunk @ r209848
g++ -g t.cc ./a.out echo OK
OK
g++ -g t.cc -O2 ./a.out
Segmentation fault (core dumped)
(gdb) disas main
Dump of assembler code for function main():
0x004004c0 +0: mov0x8,%rax
0x004004c8 +8: ud2
End of assembler dump.
It appears that GCC believes the test to invoke undefined behavior.
However, I don't see anything in the standard to support this.
P.S. Same result in C++98 and C++11
P.P.S. In the original code, the double application of typeid() was a bug.
[Bug c++/61022] New: [C++11] Bogus error: parameter packs not expanded with '...'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61022
Bug ID: 61022
Summary: [C++11] Bogus error: parameter packs not expanded
with '...'
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/14441040
// --- cut ---
template typename T struct Template {};
template typename O struct TemplateAliasStruct {
template typename T using TemplateAlias = TemplateT;
};
template template typename class... T struct Templates {};
// Using this alternate definition of Templates compiles:
// template template typename class... W void Templates() {}
template typename... W
void DoTest() {
TemplatesTemplateAliasStructW::template TemplateAlias...();
}
int main(int argc, char* argv[]) {
DoTestint, int();
return 0;
}
// --- cut ---
Using trunk @r209848:
g++ -c -std=c++11 t.cc
t.cc: In function 'void DoTest()':
t.cc:14:65: error: parameter packs not expanded with '...':
TemplatesTemplateAliasStructW::template TemplateAlias...();
^
t.cc:14:65: note: 'W'
The test compiles cleanly with Clang.
[Bug tree-optimization/61009] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/14380607
[Bug tree-optimization/61009] Incorrect jump threading in dom
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61009 --- Comment #4 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Andrew Pinski from comment #2) Most likely related to bug 60902. Teresa, could you verify whether r209860 (for PR60902) fixes this one as well?
[Bug c++/60980] [4.9/4.10 Regression] ICE in build_special_member_call, at cp/call.c:7447
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980
--- Comment #4 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Andrew Pinski from comment #3)
Note I think this code is invalid due to the struct not having a size.
Making the array non-empty makes no difference:
struct x0
{
x0 () = default;
};
struct x1
{
x0 x2[1];
void x3 ()
{
x1 ();
}
};
g++ -c -std=c++11 t.ii
t.ii: In member function ‘void x1::x3()’:
t.ii:10:13: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have array_type in build_special_member_call, at
cp/call.c:7447
... same as above.
[Bug c++/60978] -Wenum-compare warns too eagerly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978 --- Comment #7 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Richard Biener from comment #6) Warns since forever (checked up to GCC 4.3.x), confirmed. Interesting. In my non-reduced test case, the warning is new with gcc-4.9.
[Bug c++/60992] New: [4.9/4.10 Regression] ICE in tsubst_copy, at cp/pt.c:12637
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60992
Bug ID: 60992
Summary: [4.9/4.10 Regression] ICE in tsubst_copy, at
cp/pt.c:12637
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/14350545
Test:
/// --- cut ---
struct ScopeGuardGenerator { };
struct FF
{
template class F, class ... Ts
void
operator () (F ...)
{
const int n = sizeof ... (Ts);
void *mutexes[n];
auto _on_scope_exit_var_0 =
ScopeGuardGenerator () + [mutexes] { };
}
};
template class F
int operator+ (ScopeGuardGenerator, F) { return 1; }
struct D
{
template class T0, class T1, class T2, class ... T
void
operator () (T0, T1, const T2 t2, T ... t)
{
base (t2, t ...);
}
FF base;
};
D run_with_locks;
void Fn ()
{
run_with_locks ([] { }, 0, 0);
}
/// ---cut---
Using current trunk (r209848):
g++ -c -std=c++11 t2.ii
t2.ii: In instantiation of ‘FF::operator()(F, ...)::lambda() [with F = const
int; Ts = {}]’:
t2.ii:12:34: required from ‘struct FF::operator()(F, ...) [with F = const
int; Ts = {}]::lambda()’
t2.ii:12:30: required from ‘void FF::operator()(F, ...) [with F = const int;
Ts = {}]’
t2.ii:25:5: required from ‘void D::operator()(T0, T1, const T2, T ...)
[with T0 = Fn()::lambda(); T1 = int; T2 = int; T = {}]’
t2.ii:34:31: required from here
t2.ii:12:43: internal compiler error: in tsubst_copy, at cp/pt.c:12637
ScopeGuardGenerator () + [mutexes] { };
^
0x5d35cd tsubst_copy
../../gcc/cp/pt.c:12637
0x5af80b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:15150
0x5ba6f6 tsubst_expr
../../gcc/cp/pt.c:13979
0x5c4097 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:11596
0x5c33f5 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:12045
0x5c2c4b tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:11561
0x5d55a0 tsubst_decl
../../gcc/cp/pt.c:11043
0x5c388f tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:11492
0x5bb12c tsubst_expr
../../gcc/cp/pt.c:13438
0x5bb249 tsubst_expr
../../gcc/cp/pt.c:13586
0x5b8399 instantiate_decl(tree_node*, int, bool)
../../gcc/cp/pt.c:19875
0x5f4147 instantiate_class_template_1
../../gcc/cp/pt.c:9334
0x5f4147 instantiate_class_template(tree_node*)
../../gcc/cp/pt.c:9402
0x6879f3 complete_type(tree_node*)
../../gcc/cp/typeck.c:134
0x5afa30 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:15247
0x5b19bb tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:14362
0x5ba6f6 tsubst_expr
../../gcc/cp/pt.c:13979
0x5bd579 tsubst_expr
../../gcc/cp/pt.c:13489
0x5ba0a3 tsubst_expr
../../gcc/cp/pt.c:13381
0x5bb249 tsubst_expr
../../gcc/cp/pt.c:13586
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
The test compiles cleanly with Clang and gcc-4.8 (at least the version I have).
[Bug c++/60978] New: [4.9 Regression] -Wenum-compare warns too eagerly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978
Bug ID: 60978
Summary: [4.9 Regression] -Wenum-compare warns too eagerly
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:
enum { A };
enum { B };
int foo(int x)
{
return x ? A : B;
}
gcc -c -Wall t.c
# no warnings
g++ -c t.c
t.c: In function ‘int foo(int)’:
t.c:6:12: warning: enumeral mismatch in conditional expression: ‘anonymous
enum’ vs ‘anonymous enum’ [-Wenum-compare]
return x ? A : B;
^
First, there is nothing to warn about here (in real code, I return IPPROTO_ICMP
or IPPROTO_ICMPV66 depending on address family).
Second, why is this pointing to the comparison and references enum-compare?
There is no comparison of unrelated enums here.
[Bug c++/60978] [4.9 Regression] -Wenum-compare warns too eagerly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60978 --- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com --- (In reply to Andrew Pinski from comment #1) This is documented to do this even in 4.8 (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Warning-Options.html): In C++ enumeral mismatches in conditional expressions are also diagnosed and the warning is enabled by default. It also says In C this warning is enabled by -Wall, but in fact gcc -Wall does NOT warn. In any case, warning when two *anonymous* enums are used like they are here to return an integer seems of no value whatsoever.
[Bug c++/60980] New: [4.9/4.10 Regression] ICE in build_special_member_call, at cp/call.c:7447
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980
Bug ID: 60980
Summary: [4.9/4.10 Regression] ICE in
build_special_member_call, at cp/call.c:7447
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:
struct x0
{
x0 () = default;
};
struct x1
{
x0 x2[];
void x3 ()
{
x1 ();
}
};
Using trunk @r209848 (2014-04-27 17:18:40 -0700 (Sun, 27 Apr 2014)):
g++ -c -std=c++11 -c t.ii
t.ii: In member function ‘void x1::x3()’:
t.ii:10:13: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have array_type in build_special_member_call, at
cp/call.c:7447
x1 ();
^
0xd6cad4 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.c:9180
0x55d587 tree_check3
../../gcc/tree.h:2761
0x55d587 build_special_member_call(tree_node*, tree_node*, vectree_node*,
va_gc, vl_embed**, tree_node*, int, int)
../../gcc/cp/call.c:7447
0x6b5597 build_value_init(tree_node*, int)
../../gcc/cp/init.c:348
0x6b5179 build_value_init_noctor(tree_node*, int)
../../gcc/cp/init.c:419
0x6b560c build_value_init(tree_node*, int)
../../gcc/cp/init.c:367
0x5fd734 build_functional_cast(tree_node*, tree_node*, int)
../../gcc/cp/typeck2.c:1898
0x6656a0 cp_parser_functional_cast
../../gcc/cp/parser.c:23323
0x65ed42 cp_parser_postfix_expression
../../gcc/cp/parser.c:5900
0x662193 cp_parser_unary_expression
../../gcc/cp/parser.c:7188
0x662e7f cp_parser_binary_expression
../../gcc/cp/parser.c:7893
0x663361 cp_parser_assignment_expression
../../gcc/cp/parser.c:8131
0x6658c3 cp_parser_expression
../../gcc/cp/parser.c:8293
0x6660ec cp_parser_expression
../../gcc/cp/parser.c:8332
0x6660ec cp_parser_expression_statement
../../gcc/cp/parser.c:9651
0x65afc8 cp_parser_statement
../../gcc/cp/parser.c:9502
0x65bdf9 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:9774
0x65bf66 cp_parser_compound_statement
../../gcc/cp/parser.c:9728
0x66d14b cp_parser_function_body
../../gcc/cp/parser.c:18755
0x66d14b cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:18791
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
[Bug c++/60980] [4.9/4.10 Regression] ICE in build_special_member_call, at cp/call.c:7447
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60980 --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/14366603
[Bug debug/60929] New: [4.8/4.9/4.10 regression] ICE in get_ref_die_offset, at dwarf2out.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60929 Bug ID: 60929 Summary: [4.8/4.9/4.10 regression] ICE in get_ref_die_offset, at dwarf2out.c Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: ppluzhnikov at google dot com Created attachment 32658 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32658action=edit test case Using trunk @r209546: g++ -fdebug-types-section -gdwarf-4 -fmax-errors=1 '-std=gnu++11' -S t.cc echo OK OK g++ -fdebug-types-section -gdwarf-4 -fmax-errors=1 '-std=gnu++11' -S t.cc -O2 t.cc:84:1: internal compiler error: in get_ref_die_offset, at dwarf2out.c:3553 } ^ 0x892691 get_ref_die_offset ../../gcc/dwarf2out.c:3553 0x892691 output_loc_operands ../../gcc/dwarf2out.c:2081 0x892691 output_loc_sequence(dw_loc_descr_node*, int) ../../gcc/dwarf2out.c:2127 0x892eff output_die ../../gcc/dwarf2out.c:8558 0x892821 output_die ../../gcc/dwarf2out.c:8761 0x892821 output_die ../../gcc/dwarf2out.c:8761 0x892821 output_die ../../gcc/dwarf2out.c:8761 0x892821 output_die ../../gcc/dwarf2out.c:8761 0x892821 output_die ../../gcc/dwarf2out.c:8761 0x896841 output_comdat_type_unit ../../gcc/dwarf2out.c:9032 0x8b7b69 dwarf2out_finish ../../gcc/dwarf2out.c:24255 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. Google ref: b/14230806
[Bug c++/60836] [4.7/4.8/4.9 Regression] invalid PHI argument and ICE in verify_gimple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60836 --- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com --- Richard, back-port to 4.9/4.8 release branches? Thanks,
[Bug tree-optimization/60899] undef reference generated with -fdevirtualize-speculatively
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60899 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #6 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/13453242
[Bug c++/59295] useless warning: 'Bar' is already a friend of 'Foo' [enabled by default]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59295 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paul Pluzhnikov ppluzhnikov at google dot com --- Fixed on trunk.
[Bug tree-optimization/60849] bogus comparison result type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60849 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/13715169
[Bug c++/60836] New: [4.9 Regression] invalid PHI argument and ICE in verify_gimple
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60836
Bug ID: 60836
Summary: [4.9 Regression] invalid PHI argument and ICE in
verify_gimple
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/14002147
Using current trunk @r209347
gcc -c -O2 t.ii echo OK
OK
gcc -c -O2 t.ii -ftree-vectorize
t.ii: In function ‘double norm_(const int) [with template-parameter-1-1 =
int; template-parameter-1-2 = A]’:
t.ii:19:1: error: invalid PHI argument
norm_ (const int )
^
{pretmp_20, pretmp_20, pretmp_20, pretmp_20}
vect_p1_13.20_56 = PHI {pretmp_20, pretmp_20, pretmp_20, pretmp_20}(5),
vect_p1_13.20_60(13)
t.ii:19:1: error: invalid PHI argument
{pretmp_20, pretmp_20, pretmp_20, pretmp_20}
vect_p1_13.20_57 = PHI {pretmp_20, pretmp_20, pretmp_20, pretmp_20}(5),
vect_p1_13.20_61(13)
t.ii:19:1: error: invalid PHI argument
{pretmp_20, pretmp_20, pretmp_20, pretmp_20}
vect_p1_13.20_58 = PHI {pretmp_20, pretmp_20, pretmp_20, pretmp_20}(5),
vect_p1_13.20_62(13)
t.ii:19:1: internal compiler error: verify_gimple failed
0xb82d63 verify_gimple_in_cfg(function*)
../../gcc/tree-cfg.c:4942
0xaab2c2 execute_function_todo
../../gcc/passes.c:1853
0xaabc23 execute_todo
../../gcc/passes.c:1887
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
Test case:
int a, b;
typedef double (*NormFunc) (const int );
int
max (int p1, int p2)
{
if (p1 p2)
return p2;
return p1;
}
struct A
{
int operator () (int p1, int p2)
{
return max (p1, p2);
}
};
template class, class double
norm_ (const int )
{
char c, d;
A e;
for (; a; a++)
{
b = e (b, d);
b = e (b, c);
}
}
void
norm ()
{
static NormFunc f = norm_ int, A ;
f = 0;
}
[Bug preprocessor/60736] Crash in preprocessor including stdc-predef.h when it does not exist on glibc-based systems
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60736 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/13731165 This appears to be a 4.9 regression.
[Bug c++/60713] New: [4.8/4.9 regression] ICE in iterative_hash_expr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60713
Bug ID: 60713
Summary: [4.8/4.9 regression] ICE in iterative_hash_expr
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/13644122
Reproduces with current trunk (r208944):
g++ -c -std=c++11 t.cc echo ok
ok
g++ -c -std=c++11 t.cc -O2
t.cc: In member function ‘void x6::x7()’:
t.cc:20:7: internal compiler error: in iterative_hash_expr, at tree.c:7475
});
^
0xd78b9f iterative_hash_expr(tree_node const*, unsigned int)
../../gcc/tree.c:7475
0xd78a22 iterative_hash_expr(tree_node const*, unsigned int)
../../gcc/tree.c:7508
0xd7886b iterative_hash_expr(tree_node const*, unsigned int)
../../gcc/tree.c:7448
0x9abf3c gimplify_hasher::hash(gimple_temp_hash_elt const*)
../../gcc/gimplify.c:8908
0x9abf3c hash_tablegimplify_hasher,
xcallocator::find_slot(gimple_temp_hash_elt const*, insert_option)
../../gcc/hash-table.h:505
0x9abf3c lookup_tmp_var
../../gcc/gimplify.c:488
0x9abf3c internal_get_tmp_var
../../gcc/gimplify.c:523
0x9a4bf1 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:8358
0x9af968 gimplify_call_expr
../../gcc/gimplify.c:2375
0x9a5047 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7431
0x9a9996 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5353
0x9a50d2 gimplify_cleanup_point_expr
../../gcc/gimplify.c:5129
0x9a50d2 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7823
0x9a9996 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5353
0x9ab1f9 gimplify_body(tree_node*, bool)
../../gcc/gimplify.c:8567
0x9ab7d6 gimplify_function_tree(tree_node*)
../../gcc/gimplify.c:8720
0x8393a7 analyze_function
../../gcc/cgraphunit.c:649
0x83a65b analyze_functions
../../gcc/cgraphunit.c:1017
0x83bd55 finalize_compilation_unit()
../../gcc/cgraphunit.c:2320
0x63541e cp_write_global_declarations()
../../gcc/cp/decl2.c:4610
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
/// cut here
template class x0, class x1, class x2, class x3, class x4
int *x5 (x0 *, x2 (x1::*)(x3, x4));
class x6
{
void x7 ();
struct x8
{
int *x9;
};
void x10 (x8);
void x11 (int *, int *);
};
void
x6::x7 ()
{
x10 ({
x5 (this, x6::x11)
});
}
[Bug c++/57493] Incorrect name lookup for range loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57493 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- Dup of PR54430 *** This bug has been marked as a duplicate of bug 54430 ***
[Bug c++/57493] Incorrect name lookup for range loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57493 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com --- Dup.
[Bug c++/54430] [C++11] For-Loop: Scope of iterating variable begins too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430 --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- From PR57493: Google ref: b/9229787
[Bug c++/54430] [C++11] For-Loop: Scope of iterating variable begins too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com --- *** Bug 57493 has been marked as a duplicate of this bug. ***
[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 #8 from Paul Pluzhnikov ppluzhnikov at google dot com ---
(In reply to Mikhail Veltishchev from comment #7)
Please, can you explain how you fixed this? We have almost the same problem.
Here is the fix we deployed (test case from comment#2):
$ diff -u pr57199.cc pr57199a.cc
--- pr57199.cc 2014-03-26 13:50:25.682351842 -0700
+++ pr57199a.cc 2014-03-26 13:54:12.880279926 -0700
@@ -18,6 +18,9 @@
DestroyElements(mutable_array() + n, s - n);
}
static void DestroyElements(T* ptr, size_t num) {
+if (__builtin_expect (num == (size_t) -1, 0)) {
+ __builtin_unreachable();
+}
for (size_t i = 0; i num; i++) {
ptr[i].~T();
}
[Bug tree-optimization/60656] New: [4.8/4.9 regression] x86 vectorization produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656
Bug ID: 60656
Summary: [4.8/4.9 regression] x86 vectorization produces wrong
code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Current trunk (r208813) and gcc-4.8 are affected, 4.7 does not appear to be.
gcc -O0 t.c ./a.out
500450210036
gcc -O3 t.c ./a.out
500450200033
gcc -O2 t.c ./a.out
500450210036
gcc -O2 t.c -ftree-vectorize ./a.out
500450200033
// t.c
#include stdio.h
int
main ()
{
int v[] = {5000, 5001, 5002, 5003};
long s = 0;
int i;
for(i = 0; i 4; ++i)
{
long P = v[i];
s += P*P*P;
}
printf(%ld\n, s);
}
[Bug libstdc++/60658] New: std::atomicT* is unexpectedly not lock-free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60658
Bug ID: 60658
Summary: std::atomicT* is unexpectedly not lock-free
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
Using current trunk (r208813):
g++ -std=c++11 atomic.cc -latomic ./a.out
a.out: atomic.cc:20: int main(): Assertion `b.is_lock_free()' failed.
As far as I can tell, this is happening because
std::__atomic_baseBar*::_M_type_size()
returns sizeof(Bar) instead of returning sizeof(Bar*).
// atomic.cc
#include atomic
#include assert.h
struct Foo {
char buf[1];
};
struct Bar {
char buf[100];
};
int
main ()
{
std::atomicFoo* a;
assert (a.is_lock_free());
std::atomicBar* b;
assert (b.is_lock_free());
}
Google ref: b/13626319
[Bug c++/59295] useless warning: 'Bar' is already a friend of 'Foo' [enabled by default]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59295 --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Still broken in current head (r208736).
[Bug c++/59295] useless warning: 'Bar' is already a friend of 'Foo' [enabled by default]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59295 --- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com --- This appears to be a very old warning. Patch: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01123.html
[Bug c++/60420] New: [C++11] Bogus error: ‘const’ qualifiers cannot be applied to ‘int’ with lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60420
Bug ID: 60420
Summary: [C++11] Bogus error: ‘const’ qualifiers cannot be
applied to ‘int’ with lambda
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/13305941
Using current (r208339) trunk:
g++ -c -std=c++11 t.cc
t.cc: In instantiation of ‘struct fn(Iterator, Iterator) [with Iterator =
__gnu_cxx::__normal_iteratorint*, std::vectorint ]::lambda’:
t.cc:6:45: required from ‘void fn(Iterator, Iterator) [with Iterator =
__gnu_cxx::__normal_iteratorint*, std::vectorint ]’
t.cc:11:26: required from here
t.cc:6:38: error: ‘const’ qualifiers cannot be applied to ‘int’
auto x = [](const decltype(*begin) b) { };
^
t.cc: In instantiation of ‘struct fn(Iterator, Iterator) [with Iterator =
__gnu_cxx::__normal_iteratorconst int*, std::vectorint ]::lambda’:
t.cc:6:45: required from ‘void fn(Iterator, Iterator) [with Iterator =
__gnu_cxx::__normal_iteratorconst int*, std::vectorint ]’
t.cc:16:26: required from here
t.cc:6:38: error: ‘const’ qualifiers cannot be applied to ‘const int’
Clang accepts this test case. GCC-4.8 gives up with confused by earlier
errors, bailing out after the first error.
#include vector
template typename Iterator
void fn(Iterator begin, Iterator end)
{
auto x = [](const decltype(*begin) b) { };
}
void foo(std::vectorint vi)
{
fn(vi.begin(), vi.end());
}
void bar(const std::vectorint vi)
{
fn(vi.begin(), vi.end());
}
[Bug c++/60352] New: [C++11] Bogus error: conflicting declaration 'auto i'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60352 Bug ID: 60352 Summary: [C++11] Bogus error: conflicting declaration 'auto i' 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 Using current trunk (r208191): g++ -c t.cc -std=c++11 t.cc:2:6: error: conflicting declaration 'auto i' auto i = j; ^ t.cc:1:12: note: previous declaration as 'int i' extern int i, j; ^ Test: extern int i, j; auto i = j; Google ref: b/13213433
[Bug libstdc++/60308] New: [4.9 Regression] std::deque leaks memory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60308
Bug ID: 60308
Summary: [4.9 Regression] std::deque leaks memory
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
std::deque currently leaks memory. Test case:
#include deque
int main()
{
for (int j = 0; j 10; ++j)
{
const int ia[] = { 2, 3, 1, 4, 2, 1, 3, 0 };
std::dequeint d(ia, ia + sizeof (ia) / sizeof (ia[0]));
}
}
Using current trunk:
g++ (GCC) 4.9.0 20140221 (experimental)
g++ -g t.cc
Valgrind says:
valgrind --leak-check=yes ./a.out
==24027== HEAP SUMMARY:
==24027== in use at exit: 5,760 bytes in 20 blocks
==24027== total heap usage: 40 allocs, 20 frees, 11,520 bytes allocated
==24027==
==24027== 5,760 (640 direct, 5,120 indirect) bytes in 10 blocks are definitely
lost in loss record 2 of 2
==24027==at 0x402F2A9: operator new(unsigned long)
(valgrind/coregrind/m_replacemalloc/vg_replace_malloc.c:298)
==24027==by 0x401531: __gnu_cxx::new_allocatorint*::allocate(unsigned
long, void const*) (/gcc-svn-install/include/c++/4.9.0/ext/new_allocator.h:104)
==24027==by 0x4011C3: std::_Deque_baseint, std::allocatorint
::_M_allocate_map(unsigned long)
(/gcc-svn-install/include/c++/4.9.0/bits/stl_deque.h:549)
==24027==by 0x400DDC: std::_Deque_baseint, std::allocatorint
::_M_initialize_map(unsigned long)
(/gcc-svn-install/include/c++/4.9.0/bits/stl_deque.h:594)
==24027==by 0x400B54: std::_Deque_baseint, std::allocatorint
::_Deque_base(std::allocatorint const)
(/gcc-svn-install/include/c++/4.9.0/bits/stl_deque.h:470)
==24027==by 0x400A27: std::dequeint, std::allocatorint ::dequeint
const*(int const*, int const*, std::allocatorint const)
(/gcc-svn-install/include/c++/4.9.0/bits/stl_deque.h:909)
==24027==by 0x40094C: main (/tmp/t.cc:8)
==24027==
==24027== LEAK SUMMARY:
==24027==definitely lost: 640 bytes in 10 blocks
==24027==indirectly lost: 5,120 bytes in 10 blocks
==24027== possibly lost: 0 bytes in 0 blocks
==24027==still reachable: 0 bytes in 0 blocks
==24027== suppressed: 0 bytes in 0 blocks
Same test shows no leaks with gcc-4.8:
g++ (GCC) 4.8.3 20140109 (prerelease)
