[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
