[Bug c++/41961] New: Internal error with -O3 and -ftree-parallelize-loops
Hello! I've encountered internal compiler error which affects the whole 4.3
branch (source from vlc):
It fails with 4.3.3, 4.3.4 and 4.3-branch taken from svn (i didn't try 4.3.2).
It works ok with 4.4 branch and latest trunk.
sal...@salmin:~/gccbug$ ../systemroot/bin/g++4.3-branch -v -save-temps -O3
-ftree-parallelize-loops=2 AtmoZoneDefinition_cpped.cpp
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ./configure : (reconfigured) ./configure
--prefix=/home/salmin/systemroot --program-suffix=4.3-branch
--enable-languages=c,c++
Thread model: posix
gcc version 4.3.5 20091105 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-ftree-parallelize-loops=2'
'-shared-libgcc' '-mtune=generic' '-pthread'
/home/salmin/systemroot/libexec/gcc/x86_64-unknown-linux-gnu/4.3.5/cc1plus -E
-quiet -v -D_GNU_SOURCE -D_REENTRANT AtmoZoneDefinition_cpped.cpp
-mtune=generic -ftree-parallelize-loops=2 -O3 -fpch-preprocess -o
AtmoZoneDefinition_cpped.ii
ignoring nonexistent directory
"/home/salmin/systemroot/lib/gcc/x86_64-unknown-linux-gnu/4.3.5/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/salmin/systemroot/lib/gcc/x86_64-unknown-linux-gnu/4.3.5/../../../../include/c++/4.3.5
/home/salmin/systemroot/lib/gcc/x86_64-unknown-linux-gnu/4.3.5/../../../../include/c++/4.3.5/x86_64-unknown-linux-gnu
/home/salmin/systemroot/lib/gcc/x86_64-unknown-linux-gnu/4.3.5/../../../../include/c++/4.3.5/backward
/usr/local/include
/home/salmin/systemroot/include
/home/salmin/systemroot/lib/gcc/x86_64-unknown-linux-gnu/4.3.5/include
/home/salmin/systemroot/lib/gcc/x86_64-unknown-linux-gnu/4.3.5/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-ftree-parallelize-loops=2'
'-shared-libgcc' '-mtune=generic' '-pthread'
/home/salmin/systemroot/libexec/gcc/x86_64-unknown-linux-gnu/4.3.5/cc1plus
-fpreprocessed AtmoZoneDefinition_cpped.ii -quiet -dumpbase
AtmoZoneDefinition_cpped.cpp -mtune=generic -auxbase AtmoZoneDefinition_cpped
-O3 -version -ftree-parallelize-loops=2 -o AtmoZoneDefinition_cpped.s
GNU C++ (GCC) version 4.3.5 20091105 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.5 20091105 (prerelease), GMP version
4.3.1, MPFR version 2.4.1-p2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 75c935b73fe74f5f276e5cfd3e1d84c4
AtmoZoneDefinition.cpp: In member function 'void
CAtmoZoneDefinition::Fill(unsigned char)':
AtmoZoneDefinition.cpp:22: internal compiler error: in get_smt_for, at
tree-ssa-alias.c:3310
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Removing either -O3 or -ftree-parallelize-loops avoids the crash.
You can find the preprocessed source file here:
http://crocodile.iis.nsk.su/~salmin/AtmoZoneDefinition_cpped.cpp
I can try to reduce it if necessary.
--
Summary: Internal error with -O3 and -ftree-parallelize-loops
Product: gcc
Version: 4.3.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexey dot salmin at gmail dot com
GCC build triplet: Debian, x86_64
GCC host triplet: Debian, x86_64
GCC target triplet: Debian, x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41961
[Bug c++/41961] Internal error with -O3 and -ftree-parallelize-loops
--- Comment #1 from alexey dot salmin at gmail dot com 2009-11-06 04:38 --- > Hello! I've encountered internal compiler error which affects > the whole 4.3 branch (source from vlc): I mean I've encountered it trying to compile vlc's source, source of gcc was taken from gcc.gnu.org/svn :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41961
[Bug rtl-optimization/43907] New: yet another missed restrict optimization
Originally posted here: http://gcc.gnu.org/ml/gcc-help/2010-04/msg00233.html
Consider the following code:
sal...@salmin:~$ cat restrict1.c
void f(int *a, const int *restrict b) {
*a++ = *b + 1;
*a++ = *b + 1;
}
"const *restrict" guarantee that *b will not be modified inside f and we can
eliminate a load in the second statement. However:
sal...@salmin:~$ ./systemroot/bin/gcc-trunk-158628 -S -O4 -std=gnu99
restrict1.c
sal...@salmin:~$ grep -v '[.:]' restrict1.s
movl(%rsi), %eax
addl$1, %eax
movl%eax, (%rdi)
movl(%rsi), %eax
addl$1, %eax
movl%eax, 4(%rdi)
ret
But if we add a restrict keyword to the "a" definition it helps surprisingly:
sal...@salmin:~$ cat restrict2.c
void f(int *restrict a, const int *restrict b) {
*a++ = *b + 1;
*a++ = *b + 1;
}
sal...@salmin:~$ ./systemroot/bin/gcc-trunk-158628 -S -O4 -std=gnu99
restrict2.c
sal...@salmin:~$ grep -v '[.:]' restrict2.s
movl(%rsi), %eax
addl$1, %eax
movl%eax, (%rdi)
movl%eax, 4(%rdi)
ret
Not sure if it's a duplicate bug, other restrict-related bugs I've checked
seemed different to me.
--
Summary: yet another missed restrict optimization
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: alexey dot salmin at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43907
[Bug rtl-optimization/43907] yet another missed restrict optimization
--- Comment #2 from alexey dot salmin at gmail dot com 2010-04-27 09:46 --- > restrict only disambiguates against other restrict pointers. Can you please support that assertion with a reference? ISO/IEC 9899:TC2 Committee Draft May 6, 2005, 6.7.3 paragraph 7 > An object that is accessed through a restrict-qualified > pointer has a special association with that pointer. > This association, defined in 6.7.3.1 below, requires > that all accesses to that object use, directly or > indirectly, the value of that particular pointer) > The intended use of the restrict qualifier (like the > register storage class) is to promote optimization, > and deleting all instances of the qualifier from all > preprocessing translation units composing a conforming > program does not change its meaning (i.e., observable > behavior). As far as I understand that paragraph it says nothing about _other_ restrict pointers. It plainly says that any access to the memory which "b" points to will be made using "b" or its derivatives. And since "b" points to "const int" that memory can not be modified inside the "f" procedure. Since I wasn't sure I first asked that question in gcc-help mailing list [1]. Ian Lance Taylor [2] and Manuel López-Ibáñez [3] agreed that it is a missed optimization. [1] http://gcc.gnu.org/ml/gcc-help/2010-04/msg00233.html [2] http://gcc.gnu.org/ml/gcc-help/2010-04/msg00250.html [3] http://gcc.gnu.org/ml/gcc-help/2010-04/msg00256.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43907
[Bug middle-end/14192] Restrict pointers don't help
--- Comment #13 from alexey dot salmin at gmail dot com 2010-04-28 15:53
---
Sorry, but I still don't get it :( Why exactly we can't remove the second load
of "*b"?
void f(int *a, const int *restrict b) {
*a++ = *b + 1;
*a++ = *b + 1;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14192
