[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 izamyatin at gmail dot com --- Created attachment 31509 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31509action=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 izamyatin at gmail dot com --- 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 dominiq at lps dot ens.fr --- 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 dominiq at lps dot ens.fr --- 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 anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #6 from Harald Anlauf anlauf at gmx dot de --- (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 hjl.tools at gmail dot com 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 dominiq at lps dot ens.fr 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 hjl.tools at gmail dot com ---
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 dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |NEW --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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 trippels at gcc dot gnu.org ---
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 :
test:
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 anlauf at gmx dot de --- 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 mpolacek at gcc dot gnu.org 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 dominiq at lps dot ens.fr changed: What|Removed |Added Summary|Memory leak when|[4.9 Regression] Memory |deallocating polymorphic|leak when deallocating ||polymorphic --- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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 townsend at astro dot wisc.edu --- (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 nheghathivhistha at gmail dot com changed: What|Removed |Added CC||nheghathivhistha at gmail dot com --- Comment #11 from David Kredba nheghathivhistha at gmail dot com --- 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 nheghathivhistha at gmail dot com --- (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 dominiq at lps dot ens.fr --- 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 nheghathivhistha at gmail dot com --- 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 hjl.tools at gmail dot com 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=optimized out, argv=optimized out) 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 hjl.tools at gmail dot com changed: What|Removed |Added CC||rguenther at suse dot de --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- 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 steven at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #14 from Steven Bosscher steven at gcc dot gnu.org --- 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 hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-24 Ever confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- -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 hjl.tools at gmail dot com --- -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 steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #9 from Steven Bosscher steven at gcc dot gnu.org --- (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 hjl.tools at gmail dot com 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 steven at gcc dot gnu.org changed: What|Removed |Added CC||chris at bubblescope dot net --- Comment #18 from Steven Bosscher steven at gcc dot gnu.org --- *** 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 steven at gcc dot gnu.org 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 steven at gcc dot gnu.org --- 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 steven at gcc dot gnu.org changed:
What|Removed |Added
CC||steven at gcc dot gnu.org
--- Comment #6 from Steven Bosscher steven at gcc dot gnu.org ---
(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 steven at gcc dot gnu.org changed: What|Removed |Added Attachment #15079|0 |1 is obsolete|| --- Comment #29 from Steven Bosscher steven at gcc dot gnu.org --- 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 steven at gcc dot gnu.org changed: What|Removed |Added Attachment #15108|0 |1 is obsolete|| --- Comment #30 from Steven Bosscher steven at gcc dot gnu.org --- 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 steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #31 from Steven Bosscher steven at gcc dot gnu.org --- 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 steven at gcc dot gnu.org changed: What|Removed |Added Attachment #30019|0 |1 is obsolete|| --- Comment #6 from Steven Bosscher steven at gcc dot gnu.org --- 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 steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Steven Bosscher steven at gcc dot gnu.org --- 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 steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-24 Ever confirmed|0 |1 --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org --- 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 steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #9 from Steven Bosscher steven at gcc dot gnu.org --- 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 steven at gcc dot gnu.org 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 steven at gcc dot gnu.org --- 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 steven at gcc dot gnu.org 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 steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Steven Bosscher steven at gcc dot gnu.org --- 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 steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Steven Bosscher steven at gcc dot gnu.org --- 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 steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #9 from Steven Bosscher steven at gcc dot gnu.org --- 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 steven at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Steven Bosscher steven at gcc dot gnu.org --- 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 tg at mirbsd dot org --- 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
