[Bug tree-optimization/59591] New: ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:156 for -march=core-avx2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59591 Bug ID: 59591 Summary: ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:156 for -march=core-avx2 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: izamyatin at gmail dot com Target: x86 Started after r206069 and reproduced on 481.wrf from spec2006 Reduced testcase attached Options for reproducing gfortran -O2 -ftree-vectorize -march=core-avx2 -c
[Bug tree-optimization/59591] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:156 for -march=core-avx2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59591 --- Comment #1 from Igor Zamyatin --- Created attachment 31509 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31509&action=edit small testcase
[Bug tree-optimization/59523] [4.9 Regression] r205856 caused internal compiler error: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59523 --- Comment #7 from Igor Zamyatin --- Seems to cause PR59591
[Bug fortran/59589] Memory leak when deallocating polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589 --- Comment #4 from Dominique d'Humieres --- On x86_64-apple-darwin10.8, gcc version 4.8.2, with the call system line commented, valgrind gives: ==42524== HEAP SUMMARY: ==42524== in use at exit: 88 bytes in 1 blocks ==42524== total heap usage: 37 allocs, 36 frees, 400,004,301 bytes allocated ==42524== ==42524== LEAK SUMMARY: ==42524==definitely lost: 0 bytes in 0 blocks ==42524==indirectly lost: 0 bytes in 0 blocks ==42524== possibly lost: 0 bytes in 0 blocks ==42524==still reachable: 0 bytes in 0 blocks ==42524== suppressed: 88 bytes in 1 blocks ==42524== ==42524== For counts of detected and suppressed errors, rerun with: -v ==42524== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) (I don't have valgrind for darwin13).
[Bug fortran/59589] Memory leak when deallocating polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589 --- Comment #5 from Dominique d'Humieres --- The test also succeeds on x86_64-apple-darwin13 (clean r206033 or heavily patched r206191) when compiled with -fsanitize=leak.
[Bug fortran/59589] Memory leak when deallocating polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589 Harald Anlauf changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #6 from Harald Anlauf --- (In reply to Dominique d'Humieres from comment #4) > On x86_64-apple-darwin10.8, gcc version 4.8.2, with the call system line > commented, valgrind gives: > > ==42524== HEAP SUMMARY: > ==42524== in use at exit: 88 bytes in 1 blocks > ==42524== total heap usage: 37 allocs, 36 frees, 400,004,301 bytes > allocated > ==42524== > ==42524== LEAK SUMMARY: > ==42524==definitely lost: 0 bytes in 0 blocks > ==42524==indirectly lost: 0 bytes in 0 blocks > ==42524== possibly lost: 0 bytes in 0 blocks > ==42524==still reachable: 0 bytes in 0 blocks > ==42524== suppressed: 88 bytes in 1 blocks > ==42524== > ==42524== For counts of detected and suppressed errors, rerun with: -v > ==42524== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) > > (I don't have valgrind for darwin13). On i686-pc-linux-gnu, 4.9.0, and reducing the array size by 1/10, I get: ==31916== HEAP SUMMARY: ==31916== in use at exit: 40,000,000 bytes in 10 blocks ==31916== total heap usage: 61 allocs, 51 frees, 40,007,249 bytes allocated ==31916== ==31916== 4,000,000 bytes in 1 blocks are possibly lost in loss record 1 of 2 ==31916==at 0x402913D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==31916==by 0x8049F45: main (test_leak.f90:24) ==31916== ==31916== 36,000,000 bytes in 9 blocks are definitely lost in loss record 2 of 2 ==31916==at 0x402913D: malloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==31916==by 0x8049F45: main (test_leak.f90:24) ==31916== ==31916== LEAK SUMMARY: ==31916==definitely lost: 36,000,000 bytes in 9 blocks ==31916==indirectly lost: 0 bytes in 0 blocks ==31916== possibly lost: 4,000,000 bytes in 1 blocks ==31916==still reachable: 0 bytes in 0 blocks ==31916== suppressed: 0 bytes in 0 blocks
[Bug tree-optimization/59591] [4.9 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:156 for -march=core-avx2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59591 H.J. Lu changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|ICE in |[4.9 Regression] ICE in |vect_get_vec_def_for_stmt_c |vect_get_vec_def_for_stmt_c |opy, at |opy, at |tree-vect-stmts.c:156 for |tree-vect-stmts.c:156 for |-march=core-avx2|-march=core-avx2
[Bug tree-optimization/59591] [4.9 Regression] ICE in vect_get_vec_def_for_stmt_copy, at tree-vect-stmts.c:156 for -march=core-avx2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59591 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-24 Ever confirmed|0 |1
[Bug lto/59582] LTO discards symbol that defined as weak elsewhere
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59582 --- Comment #3 from H.J. Lu --- Works for me: [hjl@gnu-6 pr59582]$ cat main.c int callback() { return 0; } int main() { return s_func(); } [hjl@gnu-6 pr59582]$ cat ext.c __attribute__((weak)) int callback() { return 1; } int s_func() { return callback(); } [hjl@gnu-6 pr59582]$ make /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -c -o ext.o ext.c /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -flto -c -o main.o main.c /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -flto ext.o main.o -o e [hjl@gnu-6 pr59582]$ ld -V GNU ld (GNU Binutils) 2.24.51.20131224 Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 i386linux elf_l1om elf_k1om [hjl@gnu-6 pr59582]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -v Using built-in specs. COLLECT_GCC=/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc Target: x86_64-unknown-linux-gnu Configured with: /export/gnu/import/git/gcc/configure --enable-languages=c,c++,fortran --disable-bootstrap --prefix=/usr/gcc-4.9.0 --with-local-prefix=/usr/local --enable-gnu-indirect-function --with-fpmath=sse Thread model: posix gcc version 4.9.0 20131223 (experimental) (GCC) [hjl@gnu-6 pr59582]$
[Bug fortran/59589] Memory leak when deallocating polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |NEW --- Comment #7 from Dominique d'Humieres --- > On i686-pc-linux-gnu, 4.9.0, and reducing the array size by 1/10, I get: ... So confirmed. It looks like something is not properly initialized.
[Bug c++/58252] [4.9 Regression] ice in gimple_get_virt_method_for_binfo with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58252 --- Comment #9 from Markus Trippelsdorf --- Here's a small testcase that ICEs even with the patch from comment 7 applied: markus@x4 library % < test.ii typedef enum {} nsresult; class B { void *mMappedMemory; public: virtual int m_fn1(); }; class C : public virtual B {}; class D : C { virtual nsresult m_fn2(); }; nsresult D::m_fn2() { switch (0) case 0: m_fn1(); } markus@x4 library % c++ -r -nostdlib -flto -O2 test.ii lto1: internal compiler error: in record_target_from_binfo, at ipa-devirt.c:673
[Bug tree-optimization/59592] New: Segmentation fault in fold_comparison at -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59592 Bug ID: 59592 Summary: Segmentation fault in fold_comparison at -O1 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: antoine.balestrat at gmail dot com Hello ! The following testcase makes GCC 4.9.0 as of 20131224 segfault at -O1. $ cat seg.c long a, b; void f(void) { if(0) { int c, d; lbl1: for(c = 0; c < 1; c++) for(b = 0; b < 1;); d %= d; lbl2: d ? : 1; } if(a++) goto lbl1; int e = 1; if((a ^= a ? : 0) < (e && (e %= e))) goto lbl2; int *p = &e; } $ xgcc -O1 seg.c seg.c: In function âfâ: seg.c:26:1: internal compiler error: Segmentation fault } ^ 0x9d80bf crash_signal ../../srcdir/gcc/toplev.c:336 0x79a239 fold_comparison ../../srcdir/gcc/fold-const.c:9078 0x7a318b fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*) ../../srcdir/gcc/fold-const.c:12953 0xa0fe01 cleanup_control_expr_graph ../../srcdir/gcc/tree-cfgcleanup.c:112 0xa0fe01 cleanup_control_flow_bb ../../srcdir/gcc/tree-cfgcleanup.c:187 0xa0fe01 cleanup_tree_cfg_bb ../../srcdir/gcc/tree-cfgcleanup.c:605 0xa118a8 cleanup_tree_cfg_1 ../../srcdir/gcc/tree-cfgcleanup.c:650 0xa118a8 cleanup_tree_cfg_noloop ../../srcdir/gcc/tree-cfgcleanup.c:706 0xa118a8 cleanup_tree_cfg() ../../srcdir/gcc/tree-cfgcleanup.c:761 0x92e1d4 execute_function_todo ../../srcdir/gcc/passes.c:1808 0x92eab3 execute_todo ../../srcdir/gcc/passes.c:1884 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 c/59593] New: [arm big-endian] using "ldrh" access a immediate which stored in a memory by word
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59593 Bug ID: 59593 Summary: [arm big-endian] using "ldrh" access a immediate which stored in a memory by word Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: spf_zju at 126 dot com the C code like this: short int a = 1; int test() { return 922 * a; } compile the C code : arm-eabi-gcc -mbig-endian -O2 -S bar.c -o bar.s the bar.s like this : movw r3, #:lower16:.LANCHOR0 movt r3, #:upper16:.LANCHOR0 ldrh r0, [r3,#0] ldrh r3, .L2 smulbb r0, r0, r3 bx lr .L3: .align 2 .L2: .word 922 The immediate 922 is stored in .L2, in arm big-endian mode ,the memory of .L2 is like this 0x039a, so when executing this "ldrh r0, [r3,#0]", the r0 is zero,so the result is wrong . also see the disassembly of bar.o : : 0: e3003000 movw r3, #0 4: e3403000 movt r3, #0 8: e1d300b0 ldrh r0,[r3] c: e1df30b4 ldrh r3,[pc,#4] ;18 10:e1b00380 smulbb r0,r0,r3 14:e12fff1e bx lr 18:039a muleq r0,sl,r3 So the return value of the function test is zero. it is wrong .
[Bug fortran/59589] Memory leak when deallocating polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589 --- Comment #8 from Harald Anlauf --- No lag with 4.8.0 (or 4.7.x) on same machine: ==8545== HEAP SUMMARY: ==8545== in use at exit: 0 bytes in 0 blocks ==8545== total heap usage: 41 allocs, 41 frees, 40,007,187 bytes allocated ==8545== ==8545== All heap blocks were freed -- no leaks are possible So it's actually a regression.
[Bug target/59593] [arm big-endian] using "ldrh" access a immediate which stored in a memory by word
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59593 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org Component|c |target Severity|critical|normal
[Bug fortran/59589] [4.9 Regression] Memory leak when deallocating polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589 Dominique d'Humieres changed: What|Removed |Added Summary|Memory leak when|[4.9 Regression] Memory |deallocating polymorphic|leak when deallocating ||polymorphic --- Comment #9 from Dominique d'Humieres --- > So it's actually a regression. Marking as a regression, even if I am not fully convinced.
[Bug fortran/59589] [4.9 Regression] Memory leak when deallocating polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589 --- Comment #10 from Rich Townsend --- (In reply to Dominique d'Humieres from comment #9) > > So it's actually a regression. > > Marking as a regression, even if I am not fully convinced. Further support from valgrind on x86_64-pc-linux-gnu: ==28614== HEAP SUMMARY: ==28614== in use at exit: 40,000,000 bytes in 10 blocks ==28614== total heap usage: 57 allocs, 47 frees, 40,004,263 bytes allocated ==28614== ==28614== 8,000,000 bytes in 2 blocks are possibly lost in loss record 1 of 2 ==28614==at 0x4C2C66D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==28614==by 0x400E7F: MAIN__ (in /home/townsend/test_leak) ==28614==by 0x401153: main (in /home/townsend/test_leak) ==28614== ==28614== 32,000,000 bytes in 8 blocks are definitely lost in loss record 2 of 2 ==28614==at 0x4C2C66D: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==28614==by 0x400E7F: MAIN__ (in /home/townsend/test_leak) ==28614==by 0x401153: main (in /home/townsend/test_leak) ==28614== ==28614== LEAK SUMMARY: ==28614==definitely lost: 32,000,000 bytes in 8 blocks ==28614==indirectly lost: 0 bytes in 0 blocks ==28614== possibly lost: 8,000,000 bytes in 2 blocks ==28614==still reachable: 0 bytes in 0 blocks ==28614== suppressed: 0 bytes in 0 blocks townsend@chell ~ $ gfortran -v Using built-in specs. COLLECT_GCC=/home/townsend/madsdk/bin/gfortran.exec COLLECT_LTO_WRAPPER=/home/townsend/madsdk/bin/../libexec/gcc/x86_64-pc-linux-gnu/4.9.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure CC=gcc --build=x86_64-pc-linux-gnu --prefix=/root/madsdk --with-gmp=/root/madsdk --with-mpfr=/root/madsdk --with-mpc=/root/madsdk --enable-languages=c,c++,fortran --disable-multilib --disable-nls --disable-libsanitizer Thread model: posix gcc version 4.9.0 20131223 (experimental) (GCC)
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris & Linux)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 David Kredba changed: What|Removed |Added CC||nheghathivhistha at gmail dot com --- Comment #11 from David Kredba --- I have the same problem with snapshot 4.9-20131222. Makefile:517: recipe for target 'x86_avx.lo' failed: libtool: compile: /var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/build/./gcc/xg++ -B/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/build/./gcc/ -nostdinc++ -nostdinc++ -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/build/x86_64-pc-linux-gnu/libstdc++-v3/include -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libstdc++-v3/libsupc++ -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libstdc++-v3/include/backward -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libstdc++-v3/testsuite/util -L/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm/config/linux/x86 -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm/config/linux -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm/config/x86 -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm/config/posix -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm/config/generic -I/var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm -mrtm -Wall -pthread -Werror -mavx -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -O2 -ggdb -pipe -march=native -mtune=native -mno-sse4.2 -mno-sse4a -mno-avx -mno-3dnow -D_GNU_SOURCE -MT x86_avx.lo -MD -MP -MF .deps/x86_avx.Tpo -c /var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/libitm/config/x86/x86_avx.cc -fPIC -DPIC -o .libs/x86_avx.o I found qt-4.8.5 reporting existence of AVX and SSE 4.2 where I have Core2 only. So now I am rebuilding my Gentoo system with -O2 -ggdb -pipe -march=native -mtune=native -mno-sse4.2 -mno-sse4a -mno-avx -mno-3dnow but GCC bootstrap ignores it and adds -mavx. Configuration of gcc source tree: /var/tmp/portage/sys-devel/gcc-4.9.0_alpha20131222/work/gcc-4.9-20131222/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.9.0-alpha20131222 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20131222/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20131222 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20131222/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20131222/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-alpha20131222/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.9.0-alpha20131222/python --enable-languages=c,c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo 4.9.0_alpha20131222 --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --disable-libgcj --enable-libgomp --disable-libmudflap --disable-libssp --enable-lto --without-cloog
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris & Linux)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 --- Comment #12 from David Kredba --- (In reply to Jakub Jelinek from comment #8) > That is a user error, just don't do that. As the user provided > CFLAGS/CXXFLAGS override the default flags, you really shouldn't be using > -mno-this and -mno-that when building gcc, because that will disable what is > required to compile gcc successfully. If you want to build gcc to support > some CPU that doesn't have AVX etc., just configure it for such a CPU. I told it to GCC bootstrap (having C,XXFlags containing -march=native -mtune=native -mno-sse4.2 -mno-sse4a -mno-avx -mno-3dnow) and it ignored it completely.
[Bug fortran/59589] [4.9 Regression] Memory leak when deallocating polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59589 --- Comment #11 from Dominique d'Humieres --- > Further support from valgrind on x86_64-pc-linux-gnu: I was not questioning the PR, but the regression: if I don't see the leak at 4.9 on my builds, there is a suspicion that the bug may have been latent and only exposed by a recent change.
[Bug tree-optimization/59594] New: wrong code (by tree vectorizer) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59594 Bug ID: 59594 Summary: wrong code (by tree vectorizer) at -O3 on x86_64-linux-gnu Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu The current gcc trunk miscompiles the following testcase on x86_64-linux at -O3 in both 32-bit and 64-bit modes. This is a regression from 4.8.x. It looks like a bug in the tree vectorizer as it goes away with -fno-tree-vectorize. $ gcc-trunk -v Using built-in specs. COLLECT_GCC=gcc-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib Thread model: posix gcc version 4.9.0 20131224 (experimental) [trunk revision 206194] (GCC) $ $ gcc-trunk -O2 small.c; a.out 0 $ gcc-trunk -O3 -fno-tree-vectorize small.c; a.out 0 $ gcc-trunk -O3 small.c; a.out 1 $ --- int printf (const char *, ...); int a; static int b[7]; int main () { for (a = 5; a >= 0; a--) { b[a + 1] = b[a]; b[a] = 1; } printf ("%d\n", b[1]); return 0; }
[Bug libitm/53113] Build fails in x86_avx.cc if AVX disabled but supported by as (Solaris & Linux)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53113 --- Comment #13 from David Kredba --- Binutils rebuilt with -mno-avx and co. not helps.
[Bug tree-optimization/59594] [4.9 Regression] wrong code (by tree vectorizer) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59594 H.J. Lu changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-24 Target Milestone|--- |4.9.0 Summary|wrong code (by tree |[4.9 Regression] wrong code |vectorizer) at -O3 on |(by tree vectorizer) at -O3 |x86_64-linux-gnu|on x86_64-linux-gnu Ever confirmed|0 |1
[Bug target/59595] New: Segmentation fault: build/genpreds -c ../../gcc/gcc/config/arm/arm.md > tmp-constrs.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59595 Bug ID: 59595 Summary: Segmentation fault: build/genpreds -c ../../gcc/gcc/config/arm/arm.md > tmp-constrs.h Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: armv5tejl-unknown-linux-gnueabi Target: armv5tejl-unknown-linux-gnueabi Build: armv5tejl-unknown-linux-gnueabi In stage2, the following segementation fault occurs: build/genpreds -c ../../gcc/gcc/config/arm/arm.md > tmp-constrs.h /bin/sh: line 1: 25814 Segmentation fault build/genpreds -c ../../gcc/gcc/config/arm/arm.md > tmp-constrs.h make[3]: *** [s-constrs-h] Error 139 make[3]: Leaving directory `/home/dave/gnu/gcc/objdir/gcc' Here is backtrace: (gdb) set args -c ../../gcc/gcc/config/arm/arm.md > tmp-constrs.h (gdb) r Starting program: /home/dave/gnu/gcc/objdir/gcc/build/genpreds -c ../../gcc/gcc/config/arm/arm.md > tmp-constrs.h Program received signal SIGSEGV, Segmentation fault. needs_variable (exp=exp@entry=0x0, var=var@entry=0x19dc4 "ival") at ../../gcc/gcc/genpreds.c:169 169 switch (GET_CODE (exp)) (gdb) p exp $1 = (rtx) 0x0 (gdb) bt #0 needs_variable (exp=exp@entry=0x0, var=var@entry=0x19dc4 "ival") at ../../gcc/gcc/genpreds.c:169 #1 0x9050 in write_tm_constrs_h () at ../../gcc/gcc/genpreds.c:1051 #2 main (argc=, argv=) at ../../gcc/gcc/genpreds.c:1400 Last successful build was r203629.
[Bug tree-optimization/59594] [4.9 Regression] wrong code (by tree vectorizer) at -O3 on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59594 H.J. Lu changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #1 from H.J. Lu --- It is caused by r204062.
[Bug rtl-optimization/57763] [4.9 Regression]: comp-goto-1.c: ICE verify_flow_info failed, error: EDGE_CROSSING missing across section boundary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57763 Steven Bosscher changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #14 from Steven Bosscher --- Lots of hot/cold partitioning fixes have been committed in the past few weeks. Uros, so you still see this bug with a recent trunk?
[Bug target/59588] Odd codes in ix86_option_override_internal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59588 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-24 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu --- -mtune=i686 is also ignored: [hjl@gnu-6 gcc]$ cat /tmp/t.c #ifndef __tune_i686__ #error "bad" #endif [hjl@gnu-6 gcc]$ gcc -m32 -S /tmp/t.c -mtune=i686 /tmp/t.c:2:2: error: #error "bad" #error "bad" ^ [hjl@gnu-6 gcc]$
[Bug target/59588] Odd codes in ix86_option_override_internal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59588 --- Comment #2 from H.J. Lu --- -march=i686 is also ignored: [hjl@gnu-6 gcc]$ gcc -m32 -S /tmp/t.c -march=i686 /tmp/t.c:2:2: error: #error "bad" #error "bad" ^ [hjl@gnu-6 gcc]$
[Bug middle-end/59285] [4.9 Regression] gcc.dg/builtin-unreachable-6.c:17:1: internal compiler error: in rtl_verify_fallthru, at cfgrtl.c:2862
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59285 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #9 from Steven Bosscher --- (In reply to Jeffrey A. Law from comment #8) > I have multiple fixes. Steven and I disagree on which is better. > > Having Richi or Jakub chime in with their opinions would help -- if they > agree with Steven, then I'll go with the majority. If they prefer mine, > then that's what we'll go with. I've proposed an alternative here: http://gcc.gnu.org/ml/gcc-patches/2013-12/msg01871.html It's not quite perfect, but it's conservative. IMHO we should address the bigger issue (what does builtin_unreachable mean, also on non-cond_exec targets?) for the next GCC stage1.
[Bug target/59588] No need to check "generic" nor change "i686" for -mtune=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59588 H.J. Lu changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug rtl-optimization/50749] Auto-inc-dec does not find subsequent contiguous mem accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50749 Steven Bosscher changed: What|Removed |Added CC||chris at bubblescope dot net --- Comment #18 from Steven Bosscher --- *** Bug 19078 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/19078] Poor quality code after loop unrolling.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078 Steven Bosscher changed: What|Removed |Added Status|ASSIGNED|RESOLVED Last reconfirmed|2004-12-19 13:23:03 |2013-12-24 Blocks||24815 Depends on||56590 Resolution|--- |DUPLICATE --- Comment #20 from Steven Bosscher --- The comments about not doing auto-increment before CSE are still relevant. *** This bug has been marked as a duplicate of bug 50749 ***
[Bug rtl-optimization/24815] loop unrolling ends up with too much reg+index addressing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24815 Bug 24815 depends on bug 19078, which changed state. Bug 19078 Summary: Poor quality code after loop unrolling. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE
[Bug rtl-optimization/20211] autoincrement generation is poor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211 Bug 20211 depends on bug 19078, which changed state. Bug 19078 Summary: Poor quality code after loop unrolling. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/22366] [meta-bug] issues related to the removal of loop.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22366 Bug 22366 depends on bug 19078, which changed state. Bug 19078 Summary: Poor quality code after loop unrolling. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19078 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE
[Bug middle-end/36770] PowerPC missed autoincrement opportunity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36770 Steven Bosscher changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #6 from Steven Bosscher --- (In reply to Gunnar von Boehn from comment #2) > Correct would be: > test2: > lwz 0,0(3) > stwu 0,4(3) > blr > > Is you can see the created bad code is just the same. > This is independent of the register pinning. At least with gcc 4.7.1 and gcc 4.9.0 (r206195) the register pinning makes all the difference. $ cat t.c register int * src asm("r15"); int test1( ){ src[1]=src[0]; src++; } int *test2(int *a ){ a[1]=a[0]; a++; return a; } $ ./cc1 -quiet -O2 t.c $ cat t.s ... .L.test1: lwz 10,0(15) mr 9,15 addi 15,15,4 stw 10,4(9) blr ... .L.test2: lwz 9,0(3) stwu 9,4(3) blr This is basically the same as bug 44281.
[Bug tree-optimization/33761] tree-copyrename and tree-dominators pessimizes gzip SPEC score
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33761 Steven Bosscher changed: What|Removed |Added Attachment #15079|0 |1 is obsolete|| --- Comment #29 from Steven Bosscher --- Comment on attachment 15079 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=15079 address accumulation patch Found to be not helpful. Would need serious updating anyway for gimple tuples world.
[Bug tree-optimization/33761] tree-copyrename and tree-dominators pessimizes gzip SPEC score
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33761 Steven Bosscher changed: What|Removed |Added Attachment #15108|0 |1 is obsolete|| --- Comment #30 from Steven Bosscher --- Comment on attachment 15108 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=15108 Complete continue heuristic patch On trunk since forever: http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00289.html
[Bug tree-optimization/33761] tree-copyrename and tree-dominators pessimizes gzip SPEC score
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33761 Steven Bosscher changed: What|Removed |Added Status|NEW |WAITING --- Comment #31 from Steven Bosscher --- Is there still a bug here?
[Bug rtl-optimization/57159] Latent bug in RTL GCSE/PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57159 Steven Bosscher changed: What|Removed |Added Attachment #30019|0 |1 is obsolete|| --- Comment #6 from Steven Bosscher --- Comment on attachment 30019 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30019 patch Committed in r199049
[Bug rtl-optimization/57159] Latent bug in RTL GCSE/PRE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57159 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Steven Bosscher --- Jules, please kindly close your fixed bugs after yourself ;-)
[Bug rtl-optimization/55294] Invalid RTL sharing in lower-subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55294 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-24 Ever confirmed|0 |1 --- Comment #3 from Steven Bosscher --- Looking for confirmation that there is a bug here...
[Bug rtl-optimization/48773] Dataflow and REG_DEAD notes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48773 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #9 from Steven Bosscher --- It's up to a pass that needs these notes to compute them.
[Bug rtl-optimization/41852] ICE from '-O -fmodulo-sched -fprofile-use -freorder-blocks-and-partition'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41852 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-24 CC||tejohnson at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Steven Bosscher --- Theresa, is this one bug you could have a look at please? Your recent work on hot/cold partitioning may well have fixed the problem here.
[Bug rtl-optimization/35362] Switch expansion Enh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35362 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-24 CC||steven at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |steven at gcc dot gnu.org Ever confirmed|0 |1
[Bug other/29842] [meta-bug] outstanding patches / issues from STMicroelectronics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29842 Bug 29842 depends on bug 29946, which changed state. Bug 29946 Summary: inept unrolling for small iteration counts http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29946 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX
[Bug rtl-optimization/29946] inept unrolling for small iteration counts
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29946 Steven Bosscher changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Steven Bosscher --- Old bug without test case => closed
[Bug rtl-optimization/25221] reload bailing out even when some regs are still available
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25221 Steven Bosscher changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Steven Bosscher --- Deserves a new look with IRA and LRA... Still a problem here?
[Bug rtl-optimization/52714] [4.7/4.8/4.9 regression] ICE in fixup_reorder_chain, at cfglayout.c:880
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714 Steven Bosscher changed: What|Removed |Added Status|NEW |WAITING --- Comment #9 from Steven Bosscher --- So... still a bug here?
[Bug rtl-optimization/47270] [4.7/4.8/4.9 Regression] GCC produces unnecessary code on -O2 and -O3 levels
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47270 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Steven Bosscher --- Apparently fixed (probably by IRA).
[Bug rtl-optimization/52714] [4.7/4.8/4.9 regression] ICE in fixup_reorder_chain, at cfglayout.c:880
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52714 --- Comment #10 from Thorsten Glaser --- Yes, we still run with the code reverted to the 4.5 version in Debian. http://patch-tracker.debian.org/patch/series/view/gcc-4.8/4.8.2-10/pr52714.diff