[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #56 from Sergei Steshenko --- "-O2 ... and 820MB peak memory use" vs "-O3 ... and 700MB peak memory use" - according to my common sense -O3 is stronger than -02 optimization, and one should expect greater memory use. So, can the above be an indication of yet another bug ? I.e. -O3 in reality does not do something it is supposed to do while -O2 does this ?
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #32 from Sergei Steshenko sergstesh at yahoo dot com 2013-03-07 10:13:40 UTC --- (In reply to comment #26) (In reply to comment #23) FYI, the original file ( http://gcc.gnu.org/bugzilla/attachment.cgi?id=17377 ) can be compiled with 'clang', albeit slowly: ... Memory consumption is about 186M. How have you measured this? From time to time I was looking at output of 'top'. The compiler pretty quickly reaches the 186M +/- mark and stays at it.
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #34 from Sergei Steshenko sergstesh at yahoo dot com 2013-03-07 17:13:42 UTC --- Somehow, with -O3 LLVM clang works a little bit faster than with -O2 - 54 minutes instead of 58 minutes, though this might be a random variation: sergei@amdam2:~/gcc_bug time ~/AFSWD/install/LLVM-3.2/binsh/clang -v gap_TlnLv4.c -O3 -c clang version 3.2 (tags/RELEASE_32/final) Target: i386-pc-linux-gnu Thread model: posix /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name gap_TlnLv4.c -mrelocation-model static -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.22 -momit-leaf-frame-pointer -v -coverage-file /home/sergei/gcc_bug/gap_TlnLv4.o -resource-dir /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2 -fmodule-cache-path /tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -fdebug-compilation-dir /home/sergei/gcc_bug -ferror-limit 19 -fmessage-length 182 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o gap_TlnLv4.o -x c gap_TlnLv4.c clang -cc1 version 3.2 based upon LLVM 3.2svn default target i386-pc-linux-gnu ignoring nonexistent directory /include #include ... search starts here: #include ... search starts here: /usr/local/include /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2/include /usr/include End of search list. real54m18.212s user52m56.062s sys 0m8.085s sergei@amdam2:~/gcc_bug . Memory consumption appears to be the same as with -O2.
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #37 from Sergei Steshenko sergstesh at yahoo dot com 2013-03-07 21:47:52 UTC --- (In reply to comment #35) (In reply to comment #34) Memory consumption appears to be the same as with -O2. Can you measure the peak memory with time? /usr/bin/time -f 'real=%e user=%U system=%S share=%P%% maxrss=%M ins=%I outs=%O mfaults=%R waits=%w' + /usr/bin/time -f 'real=%e user=%U system=%S share=%P%% maxrss=%M ins=%Iouts=%O mfaults=%R waits=%w' /mnt/sdb8/sergei/AFSWD_debug/20121021/LLVM-3.2/bin/clang -v gap_TlnLv4.c -O3 -c clang version 3.2 (tags/RELEASE_32/final) Target: i386-pc-linux-gnu Thread model: posix /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name gap_TlnLv4.c -mrelocation-model static -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.22 -momit-leaf-frame-pointer -v -coverage-file /home/sergei/gcc_bug/gap_TlnLv4.o -resource-dir /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2 -fmodule-cache-path /tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O3 -fdebug-compilation-dir /home/sergei/gcc_bug -ferror-limit 19 -fmessage-length 182 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o gap_TlnLv4.o -x c gap_TlnLv4.c clang -cc1 version 3.2 based upon LLVM 3.2svn default target i386-pc-linux-gnu ignoring nonexistent directory /include #include ... search starts here: #include ... search starts here: /usr/local/include /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2/include /usr/include End of search list. real=3323.86 user=3224.22 system=8.70 share=97%% maxrss=0 ins=82598outs=8720 mfaults=193511 waits=669 - I am not sure 'maxrss=0' makes sense. Anyway, several minutes before completion 'top' showed 224m (or 228m - I do not remember exactly) in VIRT column. When 'gcc' wokrs, the machine becomes very slowly responsive due to memory usage growth; with 'clang' I do not notice slow down. My machine is dual core with 2G of physical memory.
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326 --- Comment #23 from Sergei Steshenko sergstesh at yahoo dot com 2013-03-06 16:49:51 UTC --- FYI, the original file ( http://gcc.gnu.org/bugzilla/attachment.cgi?id=17377 ) can be compiled with 'clang', albeit slowly: sergei@amdam2:~/gcc_bug time ~/AFSWD/install/LLVM-3.2/binsh/clang -v gap_TlnLv4.c -O2 -c clang version 3.2 (tags/RELEASE_32/final) Target: i386-pc-linux-gnu Thread model: posix /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/clang -cc1 -triple i386-pc-linux-gnu -emit-obj -disable-free -disable-llvm-verifier -main-file-name gap_TlnLv4.c -mrelocation-model static -fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4 -target-linker-version 2.22 -momit-leaf-frame-pointer -v -coverage-file /home/sergei/gcc_bug/gap_TlnLv4.o -resource-dir /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2 -fmodule-cache-path /tmp/clang-module-cache -internal-isystem /usr/local/include -internal-isystem /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -O2 -fdebug-compilation-dir /home/sergei/gcc_bug -ferror-limit 19 -fmessage-length 182 -mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o gap_TlnLv4.o -x c gap_TlnLv4.c clang -cc1 version 3.2 based upon LLVM 3.2svn default target i386-pc-linux-gnu ignoring nonexistent directory /include #include ... search starts here: #include ... search starts here: /usr/local/include /mnt/sdb5/qemu/20121021/LLVM-3.2/bin/../lib/clang/3.2/include /usr/include End of search list. real58m50.364s user53m25.128s sys 0m11.641s sergei@amdam2:~/gcc_bug . Memory consumption is about 186M.
[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault in record_one_conflict, ra-conflict.c:176
--- Comment #23 from sergstesh at yahoo dot com 2010-05-23 04:49 --- Just wondering after so many adjustments - is the bug going to be fixed ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
[Bug c/40115] New: -O2 and higher causes wrong label address calculation
The following program:
cat -n main.c
1 #include stdio.h
2
3
4 int main()
5{
6__label__ lab3;
7__label__ lab4;
8
9int i = 0;
10
11i++;
12lab1: fprintf(stderr, i=%d\n, i);
13
14i++;
15lab2: fprintf(stderr, i=%d\n, i);
16
17i++;
18lab3: fprintf(stderr, i=%d\n, i);
19
20i++;
21lab4: fprintf(stderr, i=%d\n, i);
22
23fprintf(stderr, lab1=%08x\n, (unsigned)lab1);
24fprintf(stderr, lab2=%08x\n, (unsigned)lab2);
25fprintf(stderr, lab3=%08x\n, (unsigned)lab3);
26fprintf(stderr, lab4=%08x\n, (unsigned)lab4);
27
28return 0;
29}
after being compiled as
/mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/binsh/gcc -O1 -Wall -Wextra
main.c -o main_-O1
produces:
./main_-O1
i=1
i=2
i=3
i=4
lab1=08048435
lab2=08048452
lab3=0804846f
lab4=0804848c
which is correct in a sense all the labels have different addresses.
When compiled as
/mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/binsh/gcc -O2 -Wall -Wextra
main.c -c -o main_-O2.o
it produces
./main_-O2
i=1
i=2
i=3
i=4
lab1=08048430
lab2=08048430
lab3=08048430
lab4=08048430
,
which is wrong in the sense all the addresses are the same.
Please note that labels have intentionally been put against 'fprintf'
statements which are _not_ eliminated by optimization ('objdump' easily proves
this).
I have read pages ## 246 .. 248 in
http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc.pdf
, they don't mention optimizations (or did I miss it ?).
The problem also exists with gcc-3.4.6.
--
Summary: -O2 and higher causes wrong label address calculation
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergstesh at yahoo dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115
[Bug c/40115] -O2 and higher causes wrong label address calculation
--- Comment #2 from sergstesh at yahoo dot com 2009-05-12 15:43 ---
No, the documentation explicitly says
( http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc.pdf , page 247 .. 248):
5.3 Labels as Values
...
To use these values, you need to be able to jump to one. This is done with
the computed
goto statement1 , goto *exp ;. For example,
goto *ptr;
Any expression of type void * is allowed.
One way of using these constants is in initializing a static array that will
serve as a jump
table:
static void *array[] = { foo, bar, hack };
Then you can select a label with indexing, like this:
goto *array[i];
Note that this does not check whether the subscript is in boundsâarray
indexing in C never
does that.
Such an array of label values serves a purpose much like that of the switch
statement.
The switch statement is cleaner, so use that rather than an array unless the
problem does
not fit a switch statement very well.
Another use of label values is in an interpreter for threaded code. The
labels within the
interpreter function can be stored in the threaded code for super-fast
dispatching.
You may not use this mechanism to jump to code in a different function. If
you do that,
totally unpredictable things will happen. The best way to avoid this is to
store the label
address only in automatic variables and never pass it as an argument.
An alternate way to write the above example is
static const int array[] = { foo - foo, bar - foo,
hack - foo };
goto *(foo + array[i]);
,
i.e. the documentation explicitly allows to rely upon labels as values.
I actually checked putting label addresses into an array - the same problem. I
didn't publish the code here - didn't want to over-complicate the test case.
--
sergstesh at yahoo dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40115
[Bug bootstrap/39737] New: 'make' for --target=i686-pc-mingw32 fails even though 'configure' is OK
I've tried to build i686-pc-mingw32 version of gcc-4.3.3 to be used as cross-compiler on Linux for Windows, and the build failed with this error message: /mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3/./gcc/xgcc -B/mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3/./gcc/ -L/mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3/i686-pc-mingw32/winsup/mingw -L/mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3/i686-pc-mingw32/winsup/w32api/lib -isystem /mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3.src/winsup/mingw/include -isystem /mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3.src/winsup/w32api/include -B/mnt/sdb8/sergei/AFSWD_debug/install/gcc4_mingw32-4.3.3/i686-pc-mingw32/bin/ -B/mnt/sdb8/sergei/AFSWD_debug/install/gcc4_mingw32-4.3.3/i686-pc-mingw32/lib/ -isystem /mnt/sdb8/sergei/AFSWD_debug/install/gcc4_mingw32-4.3.3/i686-pc-mingw32/include -isystem /mnt/sdb8/sergei/AFSWD_debug/install/gcc4_mingw32-4.3.3/i686-pc-mingw32/sys-include -O2 -g -g -O2 -O2 -I/mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3.src/gcc/../winsup/w32api/include -O2 -g -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../.././gcc -I/mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3.src/libgcc -I/mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3.src/libgcc/. -I/mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3.src/libgcc/../gcc -I/mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3.src/libgcc/../include -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3.src/libgcc/../gcc/libgcc2.c \ In file included from ../.././gcc/tm.h:10, from /mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3.src/libgcc/../gcc/libgcc2.c:35: /mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3.src/libgcc/../gcc/config/i386/cygming.h:68:19: error: stdio.h: No such file or directory make[2]: *** [_muldi3.o] Error 1 make[2]: Leaving directory `/mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3/i686-pc-mingw32/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3' make: *** [all] Error 2 , i.e. 'stdio.h' file can't be found. Of course, the file exists in a standard location, but probably -Dinhibit_libc prevents 'xgcc' from seeing it. It's my first attempt to build a cross-compiler, so maybe I'm doing something wrong, anyway, I expect 'configure' to prevent me from making stupid mistakes. Self-built working quite fine native gcc-4.3.3 was used in the attempt to build the cross-compiler version. I am about to upload files with more info - command lines, screen output, etc. My OS is SUSE 10.3, 32 bits. -- Summary: 'make' for --target=i686-pc-mingw32 fails even though 'configure' is OK Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergstesh at yahoo dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39737
[Bug bootstrap/39737] 'make' for --target=i686-pc-mingw32 fails even though 'configure' is OK
--- Comment #1 from sergstesh at yahoo dot com 2009-04-11 13:55 --- Created an attachment (id=17618) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17618action=view) autogenerated script used to run 'configure' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39737
[Bug bootstrap/39737] 'make' for --target=i686-pc-mingw32 fails even though 'configure' is OK
--- Comment #2 from sergstesh at yahoo dot com 2009-04-11 13:57 --- Created an attachment (id=17619) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17619action=view) 'configure' screen output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39737
[Bug bootstrap/39737] 'make' for --target=i686-pc-mingw32 fails even though 'configure' is OK
--- Comment #3 from sergstesh at yahoo dot com 2009-04-11 14:00 --- Created an attachment (id=17620) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17620action=view) 'make' screen output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39737
[Bug bootstrap/39737] 'make' for --target=i686-pc-mingw32 fails even though 'configure' is OK
--- Comment #5 from sergstesh at yahoo dot com 2009-04-11 16:54 --- stdio.h at system level is where it originally was: /usr/include/stdio.h /usr/include/c++/4.2.1/tr1/stdio.h /usr/include/bits/stdio.h . Regarding 'gcc' configure options - do you mean normal native 'gcc' or the 'gcc' for cross compilation I've filed the report against ? Anyway, the answers are in the already attached http://gcc.gnu.org/bugzilla/attachment.cgi?id=17618 . Native 'gcc' was built with the same options, but without --target=i686-pc-mingw32, i.e. '--target' was not at all specified on command line. Also, there were 'binutils' elements in the paths. Do you also need 'config.log' ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39737
[Bug bootstrap/39737] 'make' for --target=i686-pc-mingw32 fails even though 'configure' is OK
--- Comment #6 from sergstesh at yahoo dot com 2009-04-11 16:55 --- Sorry, not Also, there were 'binutils' elements in the paths. , but Also, there were no 'binutils' elements in the paths. . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39737
[Bug bootstrap/39737] 'make' for --target=i686-pc-mingw32 fails even though 'configure' is OK
--- Comment #7 from sergstesh at yahoo dot com 2009-04-11 17:01 --- Regarding Could you attach the build log? - isn't it already attached http://gcc.gnu.org/bugzilla/attachment.cgi?id=17620 ? The file is gzipped because in plain form it's bigger than 1MB. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39737
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #14 from sergstesh at yahoo dot com 2009-03-03 13:36 --- 'spiral' has produced another testcase which segfaults with -O2 - the original testcase segfaults with -O1. The testcase, though has half the points if terms of FFT, is big as a file: -rw-r--r-- 1 sergei users 1656419 2009-03-03 06:36 gap_CPEodL.c.bz2 , so I think I can't upload it directly, or can I ? I can send it as Email attachment to, say, rguenth. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #16 from sergstesh at yahoo dot com 2009-03-03 14:15 --- (In reply to comment #15) Subject: Re: Segmentation fault with -O1, out of memory with -O2 On Tue, 3 Mar 2009, sergstesh at yahoo dot com wrote: --- Comment #14 from sergstesh at yahoo dot com 2009-03-03 13:36 --- 'spiral' has produced another testcase which segfaults with -O2 - the original testcase segfaults with -O1. The testcase, though has half the points if terms of FFT, is big as a file: -rw-r--r-- 1 sergei users 1656419 2009-03-03 06:36 gap_CPEodL.c.bz2 , so I think I can't upload it directly, or can I ? I can send it as Email attachment to, say, rguenth. That would be fine. Richard. I have just sent Richard an Email with 'gap_CPEodL.c.bz2' file attached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] New: Segmentation fault with -O1, out of memory with -O2
I was trying to compile autogenerated by 'spiral' 'gap_TlnLv4.c' file (to be attached). Trying to compile it with /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/binsh/gcc -O1 -fomit-frame-pointer -malign-double -fstrict-aliasing -march=native -c /tmp/spiral-sergei/gap_TlnLv4.c -o gap_TlnLv4.o1 command line I got this: /tmp/spiral-sergei/gap_TlnLv4.c: In function âRDFT_49152_1â: /tmp/spiral-sergei/gap_TlnLv4.c:172282: internal compiler error: Segmentation fault Please submit a full bug report, . Before that, trying to compile it with /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/binsh/gcc -O2 -fomit-frame-pointer -malign-double -fstrict-aliasing -march=native -c /tmp/spiral-sergei/gap_TlnLv4.c command I got this: cc1: out of memory allocating 4184025948 bytes after a total of 205533184 bytes . -- Summary: Segmentation fault with -O1, out of memory with -O2 Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergstesh at yahoo dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #1 from sergstesh at yahoo dot com 2009-02-28 15:29 --- Created an attachment (id=17377) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17377action=view) source file causing the failure The source is not preprocessed, it has only standard #include math.h in it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #2 from sergstesh at yahoo dot com 2009-02-28 15:32 --- My OS: Linux amdam2 2.6.22.19-0.2-default #1 SMP 2008-12-18 10:17:03 +0100 i686 athlon i386 GNU/Linux - SUSE 10.3 in simple English; 'gcc' is self-built 'gcc-4.3.3'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #3 from sergstesh at yahoo dot com 2009-02-28 15:34 --- There is no failure with -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #4 from sergstesh at yahoo dot com 2009-02-28 17:23 --- FWIW, 'gcc-3.4.6', when run as /mnt/sdb8/sergei/AFSWD_debug/install/gcc-3.4.6/binsh/gcc -O1 -fomit-frame-pointer -malign-double -fstrict-aliasing -c /tmp/spiral-sergei/gap_TlnLv4.c -o gap_TlnLv4.o , fails with cc1: out of memory allocating 182853324 bytes after a total of 14716928 bytes message, not with segmentation fault like 'gcc-4.3.3'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #8 from sergstesh at yahoo dot com 2009-03-01 03:03 --- Created an attachment (id=17378) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17378action=view) a smaller file with hopefully the same pattern -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #9 from sergstesh at yahoo dot com 2009-03-01 03:06 --- (In reply to comment #6) As this seems to be autogenerated from ! The SPL Program: (compose (sparse (coords (...12288 x 2 ...))(values (...1 x 12288 ...)))(compose (conjugate (..)(..))(compose (..)(.. ! node size: 12288 X 12288 can you produce a testcase with an order of magnitude less loads/stores? (thus likely just node size: 1228 x 1228)? Thanks! I've uploaded a smaller file: gap_bzAJWH.c.gz . These are intermediated files which are deleted upon successful compilation. So, I've decreased the number the points and managed to catch this one. It is: node size: 1536 X 1536. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #10 from sergstesh at yahoo dot com 2009-03-01 03:09 --- I am not sure whether it's clear - the smaller 'gap_bzAJWH.c.gz' file can be found as http://gcc.gnu.org/bugzilla/attachment.cgi?id=17378action=view attachment. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #11 from sergstesh at yahoo dot com 2009-03-01 03:54 --- (In reply to comment #5) Try -fno-move-loop-invariants. This is probably a killer on alias-improvements branch as well. Still segfault: gap_TlnLv4.c: In function âRDFT_49152_1â: gap_TlnLv4.c:172282: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. real33m52.152s user16m47.843s sys 0m9.333s [1] Exit 1 time /mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.3.3/binsh/gcc -O1 -fomit-frame-pointer -malign-double -fstrict-aliasing -fno-move-loop-invariants -c gap_TlnLv4.c . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug c++/38963] New: massive failures during 'make -k test' in 'libmudflap'
I'm building the brand new gcc-4.3.3 and I see massive failures during 'make-k test': FAIL: libmudflap.c++/pass41-frag.cxx execution test FAIL: libmudflap.c++/pass41-frag.cxx (-static) execution test FAIL: libmudflap.c++/pass41-frag.cxx ( -O) execution test FAIL: libmudflap.c++/pass41-frag.cxx (-O2) execution test FAIL: libmudflap.c++/pass41-frag.cxx (-O3) execution test Running /mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3.src/libmudflap/testsuite/libmudflap.c++/ctors.exp ... Running /mnt/sdb8/sergei/AFSWD_debug/build/gcc-4.3.3.src/libmudflap/testsuite/libmudflap.cth/cthfrags.exp ... WARNING: program timed out. FAIL: libmudflap.cth/pass37-frag.c execution test FAIL: libmudflap.cth/pass37-frag.c output pattern test WARNING: program timed out. FAIL: libmudflap.cth/pass37-frag.c (rerun 1) execution test FAIL: libmudflap.cth/pass37-frag.c (rerun 1) output pattern test WARNING: program timed out. FAIL: libmudflap.cth/pass37-frag.c (rerun 4) execution test FAIL: libmudflap.cth/pass37-frag.c (rerun 4) output pattern test WARNING: program timed out. FAIL: libmudflap.cth/pass37-frag.c (rerun 5) execution test FAIL: libmudflap.cth/pass37-frag.c (rerun 5) output pattern test WARNING: program timed out. FAIL: libmudflap.cth/pass37-frag.c (rerun 6) execution test FAIL: libmudflap.cth/pass37-frag.c (rerun 6) output pattern test WARNING: program timed out. FAIL: libmudflap.cth/pass37-frag.c (rerun 7) execution test FAIL: libmudflap.cth/pass37-frag.c (rerun 7) output pattern test WARNING: program timed out. FAIL: libmudflap.cth/pass37-frag.c (rerun 8) execution test FAIL: libmudflap.cth/pass37-frag.c (rerun 8) output pattern test WARNING: program timed out. FAIL: libmudflap.cth/pass37-frag.c (rerun 9) execution test FAIL: libmudflap.cth/pass37-frag.c (rerun 9) output pattern test WARNING: program timed out. FAIL: libmudflap.cth/pass37-frag.c (rerun 10) execution test FAIL: libmudflap.cth/pass37-frag.c (rerun 10) output pattern test WARNING: program timed out. FAIL: libmudflap.cth/pass37-frag.c (rerun 13) execution test FAIL: libmudflap.cth/pass37-frag.c (rerun 13) output pattern test WARNING: program timed out. FAIL: libmudflap.cth/pass37-frag.c (rerun 17) execution test FAIL: libmudflap.cth/pass37-frag.c (rerun 17) output pattern test WARNING: program timed out. FAIL: libmudflap.cth/pass37-frag.c (rerun 18) execution test FAIL: libmudflap.cth/pass37-frag.c (rerun 18) output pattern test WARNING: program timed out. FAIL: libmudflap.cth/pass37-frag.c (rerun 19) execution test FAIL: libmudflap.cth/pass37-frag.c (rerun 19) output pattern test WARNING: program timed out. ... . I know that test suite failures are not considered to be bugs, but the point is that I had no such failures while building gcc-4.3.2 exactly the same way with the same dependencies, so _maybe_ it's a regression failure. -- Summary: massive failures during 'make -k test' in 'libmudflap' Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergstesh at yahoo dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38963
[Bug c++/38963] massive failures during 'make -k test' in 'libmudflap'
--- Comment #1 from sergstesh at yahoo dot com 2009-01-25 06:33 --- Created an attachment (id=17179) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17179action=view) screen output of 'make -k check' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38963
[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault in record_one_conflict, ra-conflict.c:176
--- Comment #15 from sergstesh at yahoo dot com 2009-01-08 22:18 --- (In reply to comment #14) This is fixed in 4.4 by IRA: gnu-3:pts/0[29] ./xgcc -B./ -O -S /net/gnu-6/export/home/hjl/tmp/gcc_bug.i -fno-ira gcc_bug.c: In function main: gcc_bug.c:23030: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gnu-3:pts/0[30] When I enable checking in gcc 4.3, I got [...@gnu-17 gcc]$ ./xgcc -B./ /tmp/gcc_bug.i -S -O -v Reading specs from ./specs Target: i686-pc-linux-gnu Configured with: /net/gnu-13/export/gnu/src/gcc-4.3/gcc/configure --enable-languages=c --disable-bootstrap --enable-checking Thread model: posix gcc version 4.3.3 20090108 (prerelease) [gcc-4_3-branch revision 143188] (GCC) COLLECT_GCC_OPTIONS='-B./' '-S' '-O' '-v' '-mtune=generic' ./cc1 -fpreprocessed /tmp/gcc_bug.i -quiet -dumpbase gcc_bug.i -mtune=generic -auxbase gcc_bug -O -version -o gcc_bug.s GNU C (GCC) version 4.3.3 20090108 (prerelease) [gcc-4_3-branch revision 143188] (i686-pc-linux-gnu) compiled by GNU C version 4.3.2 20081105 (Red Hat 4.3.2-7), GMP version 4.2.2, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 98cd2bcb358a704593004b875ff80d57 gcc_bug.c: In function main: gcc_bug.c:23030: internal compiler error: in global_alloc, at global.c:438 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. [...@gnu-17 gcc]$ We had an overflow in max_bitnum and things went downhill after that. I do not quite understand the This is fixed in 4.4 by IRA: gnu-3:pts/0[29] ./xgcc -B./ -O -S /net/gnu-6/export/home/hjl/tmp/gcc_bug.i -fno-ira gcc_bug.c: In function main: gcc_bug.c:23030: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gnu-3:pts/0[30] part, i.e. on the one hand there is a statement that the problem is fixed in 4.4, on the other hand the example still shows internal compiler error: Segmentation fault - is this example from 4.4 ? If yes, how does Segmentation fault indicate that the problem is fixed ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
[Bug middle-end/38666] [4.3 Regression] internal compiler error: Segmentation fault in record_one_conflict, ra-conflict.c:176
--- Comment #17 from sergstesh at yahoo dot com 2009-01-08 22:26 --- (In reply to comment #16) (In reply to comment #15) This is fixed in 4.4 by IRA: gnu-3:pts/0[29] ./xgcc -B./ -O -S /net/gnu-6/export/home/hjl/tmp/gcc_bug.i -fno-ira gcc_bug.c: In function main: gcc_bug.c:23030: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gnu-3:pts/0[30] part, i.e. on the one hand there is a statement that the problem is fixed in 4.4, on the other hand the example still shows internal compiler error: Segmentation fault - is this example from 4.4 ? If yes, how does Segmentation fault indicate that the problem is fixed ? You only see Segmentation fault with -fno-ira. Am I supposed to encounter Segmentation fault at all ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
[Bug c/38666] New: internal compiler error: Segmentation fault
I've encountered this problem while compiling a mostly autogenerated C file. Here is the screen session: ~/AFSWD/install/gcc-4.3.2/binsh/gcc -v -save-temps -O1 -march=native -mtune=native -I/home/sergei/GenericBinauralFFTW/C -Wall gcc_bug.c -o gcc_bug -lm Using built-in specs. Target: i686-pc-linux-gnu Configured with: /home/sergei/AFSWD/build/gcc-4.3.2.src/configure --enable-bootstrap --enable-threads --enable-languages=c,c++,fortran,objc,obj-c++,treelang --with-mpfr=/home/sergei/AFSWD/install/mpfr-2.3.2 --with-gmp=/home/sergei/AFSWD/install/gmp-4.2.2 --prefix=/home/sergei/AFSWD/install/gcc-4.3.2 Thread model: posix gcc version 4.3.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-I/home/sergei/GenericBinauralFFTW/C' '-Wall' '-o' 'gcc_bug' /home/sergei/AFSWD/install/gcc-4.3.2/libexec/gcc/i686-pc-linux-gnu/4.3.2/cc1 -E -quiet -v -I/home/sergei/GenericBinauralFFTW/C gcc_bug.c -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 -mtune=k8 -Wall -O1 -fpch-preprocess -o gcc_bug.i ignoring nonexistent directory /home/sergei/AFSWD/install/gcc-4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/../../../../i686-pc-linux-gnu/include #include ... search starts here: #include ... search starts here: /home/sergei/GenericBinauralFFTW/C /usr/local/include /home/sergei/AFSWD/install/gcc-4.3.2/include /home/sergei/AFSWD/install/gcc-4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/include /home/sergei/AFSWD/install/gcc-4.3.2/lib/gcc/i686-pc-linux-gnu/4.3.2/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O1' '-I/home/sergei/GenericBinauralFFTW/C' '-Wall' '-o' 'gcc_bug' /home/sergei/AFSWD/install/gcc-4.3.2/libexec/gcc/i686-pc-linux-gnu/4.3.2/cc1 -fpreprocessed gcc_bug.i -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 -mtune=k8 -quiet -dumpbase gcc_bug.c -auxbase gcc_bug -O1 -Wall -version -o gcc_bug.s GNU C (GCC) version 4.3.2 (i686-pc-linux-gnu) compiled by GNU C version 4.3.2, GMP version 4.2.2, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 59348dc68d2c7c94f733394a90fbab10 gcc_bug.c: In function main: gcc_bug.c:23030: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. . I am about to upload 'gcc_bug.i' file generated by the above command. -- Summary: internal compiler error: Segmentation fault Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergstesh at yahoo dot com GCC build triplet: Linux amdam2 2.6.22.19-0.1-default #1 SMP 2008-10-14 22:17:43 +0 GCC host triplet: Linux amdam2 2.6.22.19-0.1-default #1 SMP 2008-10-14 22:17:43 +0 GCC target triplet: Linux amdam2 2.6.22.19-0.1-default #1 SMP 2008-10-14 22:17:43 +0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
[Bug c/38666] internal compiler error: Segmentation fault
--- Comment #1 from sergstesh at yahoo dot com 2008-12-29 21:50 --- Created an attachment (id=17005) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17005action=view) 'gcc_bug.i.gz' file produced by 'gcc' and 'gzip' from the input 'gcc_bug.c' one Source with all the files included. I had to 'gzip' it because otherwise Bugzilla doesn't accept it because of size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
[Bug c/38666] internal compiler error: Segmentation fault
--- Comment #2 from sergstesh at yahoo dot com 2008-12-29 21:53 --- The bug is data-dependent. If inside the 'for' loop I replace all the coefficients with 1.0, the failure is graceful: cc1: out of memory allocating 4054207356 bytes after a total of 105562112 bytes . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
[Bug c/38666] internal compiler error: Segmentation fault
--- Comment #3 from sergstesh at yahoo dot com 2008-12-29 21:57 --- No problem occurs with -O0; with -O2, -O3 'gcc' also exits gracefully: cc1: out of memory allocating 4283978752 bytes after a total of 228749312 bytes . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
[Bug c/38666] internal compiler error: Segmentation fault
--- Comment #4 from sergstesh at yahoo dot com 2008-12-29 22:45 --- Just to make sure - my OS is 32 bits SUSE-10.3, though the CPU is 64 bits capable. -- sergstesh at yahoo dot com changed: What|Removed |Added Severity|normal |major Component|middle-end |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
[Bug c/38666] internal compiler error: Segmentation fault
--- Comment #6 from sergstesh at yahoo dot com 2008-12-30 00:00 --- (In reply to comment #5) The function is simply too big and we likely use most of the memory computing and storing the const reals. A case for closer investigation. (In reply to comment #5) The function is simply too big and we likely use most of the memory computing and storing the const reals. A case for closer investigation. My primary concern is segmentation fault, not the cases when 'gcc' can't allocate enough memory and reports the problem clearly. It also appears gcc-3.4.6 is much less memory-hungry - I'm checking it right now. -- sergstesh at yahoo dot com changed: What|Removed |Added Severity|normal |major Component|middle-end |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
[Bug c/38666] internal compiler error: Segmentation fault
--- Comment #8 from sergstesh at yahoo dot com 2008-12-30 00:08 --- (In reply to comment #7) (In reply to comment #6) My primary concern is segmentation fault, not the cases when 'gcc' can't allocate enough memory and reports the problem clearly. The seg fault is most likely some recursive function gone wrong. I guess the recursive function is in 'gcc'. Anyway, if you look at the code (probably you've already looked), you'll find that though it's long, it's simple. I mean, there is a whole lot of similar relatively simple expressions like this one: accumulator[sample_number] += 5.375239973e-09 * exp(-5.409392003e-06 * d_sample_number) * cos(1.954049995e-01 * two_pi_times_sample_number - (1.325159989e+00)); . So, simplistically, because the expressions are simple and the optimization level is low, I do not see too much place for deep recursion, but I'm unfamiliar with 'gcc' internals. -- sergstesh at yahoo dot com changed: What|Removed |Added Severity|normal |major Component|middle-end |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38666
[Bug c/35709] New: severe perfromance degradation with float complex type
Compiling and running the same test case with gcc-4.2.3 and gcc-4.3.0 shows that in the latter case performance takes an almost 3x hit: [EMAIL PROTECTED]:/mnt/sda1/sergei/learning_octave /maxtor5/sergei/AppsFromScratchWD/install/gcc-4.2.3/binsh/gcc -Wall -mtune=native -march=native -O2 -msse -lm complex_multiplication_testcase.c -o complex_multiplication_testcase [EMAIL PROTECTED]:/mnt/sda1/sergei/learning_octave time ./complex_multiplication_testcase executions of straightforward_multiply_with_ptrs() took 6.77 seconds at line number 136 of 'complex_multiplication_testcase.c' file executions of straightforward_multiply() took 6.74 seconds at line number 154 of 'complex_multiplication_testcase.c' file executions of straightforward_multiply_2_signals() took 8.62 seconds at line number 172 of 'complex_multiplication_testcase.c' file real0m22.326s user0m22.121s sys 0m0.012s [EMAIL PROTECTED]:/mnt/sda1/sergei/learning_octave /maxtor5/sergei/AppsFromScratchWD/install/gcc-4.3.0/binsh/gcc -Wall -mtune=native -march=native -O2 -msse -lm complex_multiplication_testcase.c -o complex_multiplication_testcase [EMAIL PROTECTED]:/mnt/sda1/sergei/learning_octave time ./complex_multiplication_testcase executions of straightforward_multiply_with_ptrs() took 18.17 seconds at line number 136 of 'complex_multiplication_testcase.c' file executions of straightforward_multiply() took 16.91 seconds at line number 154 of 'complex_multiplication_testcase.c' file executions of straightforward_multiply_2_signals() took 30.64 seconds at line number 172 of 'complex_multiplication_testcase.c' file real1m6.306s user1m5.676s sys 0m0.056s [EMAIL PROTECTED]:/mnt/sda1/sergei/learning_octave - see, for example, executions of straightforward_multiply() took 6.74 seconds vs executions of straightforward_multiply() took 16.91 seconds and user0m22.121s vs user1m5.676s . FWIW, gcc-3.4.6 shows comparable to gcc-4.2.3 results, albeit slightly worse, so it looks like the issue is very much gcc-4.3.0 specific. I'll upload the test case. -- Summary: severe perfromance degradation with float complex type Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergstesh at yahoo dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
[Bug c/35709] severe perfromance degradation with float complex type
--- Comment #1 from sergstesh at yahoo dot com 2008-03-26 19:23 --- Created an attachment (id=15383) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15383action=view) the test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
[Bug c/35709] severe perfromance degradation with float complex type
--- Comment #2 from sergstesh at yahoo dot com 2008-03-26 19:40 --- My system: Linux amdam2 2.6.18.8-0.9-default #1 SMP Sun Feb 10 22:48:05 UTC 2008 i686 athlon i386 GNU/Linux - SUSE 10.2, the CPU is: AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ stepping 02. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
[Bug c/35709] severe perfromance degradation with float complex type
--- Comment #4 from sergstesh at yahoo dot com 2008-03-26 20:44 --- (In reply to comment #3) This was an intentional change for correctness. 4.3 uses the library implementation to handle the case of NaNs correctly. Use -fcx-limited-range if you want back the performance. Well, I'm using float complex for real time audio, so correctness of NaNs is not an issue. I think the default should have been the opposite. Why to break existing applications ? When float rather than double is used, it's most likely for non-sicentific needs, so correctness in canse of NaNs most likely isn't an issue. -- sergstesh at yahoo dot com changed: What|Removed |Added Component|middle-end |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
[Bug c/35709] severe perfromance degradation with float complex type
--- Comment #6 from sergstesh at yahoo dot com 2008-03-26 20:58 --- (In reply to comment #5) As mentioned, use -fcx-limited-range. Can't you add just _one_ command line switch: -old_behavior ? Or -gcc_4_2_3_behavior ? For example, I need FFTW3 with float rather than double, and I need its speed. I am not sure FFTW3 'configure' will add -fcx-limited-range. Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35709
[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one
--- Comment #21 from sergstesh at yahoo dot com 2008-01-20 22:30 --- Now that the flags are in this order: -Wall -Wstrict-overflow=5 : a) the warnings during compilation: [EMAIL PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 grep warn make.log lpc.c:220: warning: assuming signed overflow does not occur when simplifying conditional to constant g72x.c:249: warning: assuming signed overflow does not occur when simplifying conditional to constant sndfile.c:491: warning: the address of 'sf_error' will never be NULL aiff.c:557: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 sd2.c:540: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 sd2.c:558: warning: assuming signed overflow does not occur when changing X +- C1 cmp C2 to X cmp C1 +- C2 sndfile-play.c:292: warning: the address of #8216;status#8217; will always evaluate as #8216;true#8217; lossy_comp_test.c:1342: warning: assuming signed overflow does not occur when simplifying abs (X) to X or -X lossy_comp_test.c:1527: warning: assuming signed overflow does not occur when simplifying abs (X) to X or -X lossy_comp_test.c:761: warning: assuming signed overflow does not occur when simplifying abs (X) to X or -X lossy_comp_test.c:573: warning: assuming signed overflow does not occur when simplifying abs (X) to X or -X peak_chunk_test.c:127: warning: assuming signed overflow does not occur when simplifying division peak_chunk_test.c:194: warning: assuming signed overflow does not occur when simplifying division fix_this.c:155: warning: assuming signed overflow does not occur when simplifying abs (X) to X or -X [EMAIL PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 ; b) 'make check' still fails with the same Line 765: Signal is all zeros (-27260928, 0xFE600800). message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one
--- Comment #23 from sergstesh at yahoo dot com 2008-01-21 05:07 --- It's too bad the bug is closed just as a duplicate of another bug. The main points of this bug are: 1) the code triggering the bug uses undefined in C standards language features - behavior in case of integer overflow + signed - unsigned comparison; 2) C standard is not the only standard having some cases undefined - whenever compiler developers face an undefined case they should somehow define the case themselves and publish their definition/decision; 3) it's very desirable for the compiler developers to be consistent, i.e. whenever the undefined by standard case is encountered, the compiler behaves the same way, i.e. produces code implementing the same algorithm; 4) I do see consistency in gcc-3.4.6, gcc-4.1.2 - regardless of -O1 vs -O2 generated by gcc code functionally behaves the same way; 5) gcc-4.2.x shows lack of consistency - -O1 code behaves differently compared to -O2 one. It's a pity that newer gcc versions are less consistent than the old ones. As I suggested earlier, the cleanest solution would be _not_ to perform optimization on unclean code, thus ensuring consistency. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one
--- Comment #15 from sergstesh at yahoo dot com 2008-01-18 14:08 --- With CFLAGS='-O2 -Wstrict-overflow=5' still there is no warnings in 'make_check.log': [EMAIL PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 grep -i warn make.log sndfile.c:491: warning: the address of 'sf_error' will never be NULL sndfile-play.c:292: warning: the address of #8216;status#8217; will always evaluate as #8216;true#8217; [EMAIL PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 grep -i warn make_check.log [EMAIL PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 grep -P '\-Wstrict-overflow=5' make.log | wc -l 341 [EMAIL PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 , so I think you are right there is a bug in gcc. And there is apparently another bug. If I do _not_ have -Wstrict-overflow, I _do_ have these warnings during compilation: [EMAIL PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 grep comparison between signed and unsigned ../../gcc-4.2.2-O1/libsndfile-1.0.17/make.log floating_point_test.c:338: warning: comparison between signed and unsigned floating_point_test.c:388: warning: comparison between signed and unsigned floating_point_test.c:438: warning: comparison between signed and unsigned floating_point_test.c:488: warning: comparison between signed and unsigned floating_point_test.c:538: warning: comparison between signed and unsigned floating_point_test.c:588: warning: comparison between signed and unsigned floating_point_test.c:638: warning: comparison between signed and unsigned floating_point_test.c:688: warning: comparison between signed and unsigned [EMAIL PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 . If I have -Wstrict-overflow, I do _not_ have the above warnings: [EMAIL PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 grep comparison between signed and unsigned make.log [EMAIL PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 . I believe I should have the warnings in both cases. Folks, libsndfile is easy to compile - it has (kind of) no external dependencies, i.e. it depends only on basic libraries like libm, glibc, etc., so you can easily conduct such experiments yourselves - the the needed beef, including libsdnfile sources, is in the uploaded file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one
--- Comment #19 from sergstesh at yahoo dot com 2008-01-18 23:33 --- Regarding BTW, is your makefile adding -Wstrict-overflow after or before -Wall -Wextra?. Here is how the first action line in 'make.log' looks: 23 if /bin/sh ../../libtool --tag=CC --mode=compile /maxtor5/sergei/AppsFromScratchWD/install/gcc-4.2.2/bin/gcc -DHAVE_CONFIG_H -I. -I. -I../../src -O2 -Wstrict-overflow=5 -std=gnu99 -W -Wall -Wdeclaration-after-statement -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Waggregate-return -Wcast-align -Wcast-qual -Wnested-externs -Wshadow -Wbad-function-cast -Wwrite-strings -pipe -MT add.lo -MD -MP -MF .deps/add.Tpo -c -o add.lo add.c; \ 24 then mv -f .deps/add.Tpo .deps/add.Plo; else rm -f .deps/add.Tpo; exit 1; fi . My understanding is that whatever is given to 'configure' as CFLAGS is inserted before the flags 'configure' and friends put. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one
--- Comment #16 from sergstesh at yahoo dot com 2008-01-18 14:19 --- A general though regarding optimization - do _not_ optimize code producing warnings, and notify end user, so there will be much more incentive to write clean code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
[Bug c/34841] New: 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one
X-Bugzilla-Reason: CC I've noticed the problem while building libsndfile-1.0.17 from source after switching from SUSE 10.2 to SUSE 10.3, and thus from gcc-4.1.2 to gcc-4.2.1. I have built myself a number of 'gcc' versions: 3.4.6, 4.2.0, 4.2.1, 4.2.2. With gcc-3.4.6, gcc-4.1.2 default build of libsndfile-1.0.17 (i.e. -O2 optimization) progresses just fine, 'make check' does not fail. With all the above gcc-4.2.x default build fails during 'make check' with these error messages: Line 765: Signal is all zeros (-27260928, 0xFE600800). make[1]: *** [wav-tests] Error 1 make[1]: Leaving directory `/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17/tests' make: *** [check-recursive] Error 1 . So, I believe, the bug was introduced into gcc-4.2.0 and is still there. Setting '-O1' on 'configure' command line like this: CFLAGS=-O1 allows 'make check' to complete normally. One can see examples of successful and failing runs in the to be uploaded gcc4.2.x-O2_bug.tar.gz tarball. When unpackaged, the tarball should produce three directories of interest: gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 gcc4.2.x-O2_bug/gcc-4.2.2-O1/libsndfile-1.0.17 gcc4.2.x-O2_bug/gcc-3.4.6-O2/libsndfile-1.0.17 . In the above directories one can see 'make_check.log' files and gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17/make_check.log file contains the above error messages indicating the failure. Likewise, each of the above directories contains a simple 'run.sh' script looking like this: [EMAIL PROTECTED]:/mnt/sda8/sergei cat gcc4.2.x-O2_bug/gcc-4.2.2-O1/libsndfile-1.0.17/run.sh #!/bin/sh -v make clean 1make_clean.log 21 ./configure CC=/maxtor5/sergei/AppsFromScratchWD/install/gcc-4.2.2/bin/gcc CFLAGS=-O1 1configure.log 21 \ make 1make.log 21 \ make check 1make_check.log 21 [EMAIL PROTECTED]:/mnt/sda8/sergei . So, one can reproduce the bug (and the correct behavior) by changing the path after CC= and running the script as ./run.sh. Since I am not a libsndfile-1.0.17 developer, I am not familiar with inner workings of the library, hopefully folks on [EMAIL PROTECTED] list (unfortunately, the list does not have WEB archive) will be able to help. People on the list confirm the problem. As you all probably already know, 'libsndfile' lives here: http://www.mega-nerd.com/libsndfile/ . -- Summary: 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 - O2 optimization, OK with -O1 one Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergstesh at yahoo dot com GCC host triplet: i686-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one
--- Comment #1 from sergstesh at yahoo dot com 2008-01-18 00:40 --- The tarball: http://www.filelime.com/upload/files/gcc4.2.x-O2_bug.tar.gz . -- sergstesh at yahoo dot com changed: What|Removed |Added Summary|'make check' of libsndfile- |'make check' of libsndfile- |1.0.17 fails with gcc-4.2.2 |1.0.17 fails with gcc-4.2.2 |-O2 optimization, OK with - |-O2 optimization, OK with - |O1 one |O1 one http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one
--- Comment #3 from sergstesh at yahoo dot com 2008-01-18 01:28 --- With -O2 -fno-strict-aliasing the failure is still there, I'll check with -O2 -fwrapv right away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one
--- Comment #4 from sergstesh at yahoo dot com 2008-01-18 01:33 --- -O2 -fwrapv fixes the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one
--- Comment #6 from sergstesh at yahoo dot com 2008-01-18 01:43 --- I've tried CFLAGS='-O2 -fwrapv -Wstrict-overflow' and I see no warnings at all in 'make_check.log' file - I tried grep -i warn make_check.log. OTOH: [EMAIL PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 grep -i warn make.log sndfile.c:491: warning: the address of 'sf_error' will never be NULL sndfile-play.c:292: warning: the address of #8216;status#8217; will always evaluate as #8216;true#8217; floating_point_test.c:338: warning: comparison between signed and unsigned floating_point_test.c:388: warning: comparison between signed and unsigned floating_point_test.c:438: warning: comparison between signed and unsigned floating_point_test.c:488: warning: comparison between signed and unsigned floating_point_test.c:538: warning: comparison between signed and unsigned floating_point_test.c:588: warning: comparison between signed and unsigned floating_point_test.c:638: warning: comparison between signed and unsigned floating_point_test.c:688: warning: comparison between signed and unsigned [EMAIL PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 , but these warning say nothing about overflow since it's compilation, not execution. Did you mean CFLAGS='-O2 -fwrapv -Wstrict-overflow' or, rather, CFLAGS='-O2 -Wstrict-overflow' ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one
--- Comment #8 from sergstesh at yahoo dot com 2008-01-18 01:52 --- With CFLAGS='-O2 -Wstrict-overflow' still no warnings in 'make_check.log' and [EMAIL PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 grep -i warn make.log sndfile.c:491: warning: the address of 'sf_error' will never be NULL sndfile-play.c:292: warning: the address of #8216;status#8217; will always evaluate as #8216;true#8217; [EMAIL PROTECTED]:/mnt/sda8/sergei/gcc4.2.x-O2_bug/gcc-4.2.2-O2/libsndfile-1.0.17 . Here is a quote from a [EMAIL PROTECTED] contributor: Yep, I had the same problem when upgrading my gcc from 4.1.2 to 4.2.2. The test fails because some of the bit shuffling tricks that Eric uses there does not work correctly with 4.2.2. I backported lossy_comp_test.c from pre 1.0.18 - which does pass the test with 4.2.2 - to my 1.0.17 and the test did then run correctly again. Unfortunately, I later found out that gcc 4.2.2 with -03 does produce wrong code when I use stl:set in my c++ functions. So I now switched back to use 4.1.2. Still, if you want you may try to use the diff below that is the difference between the original version from 1.0.17 and the patched version that works with gcc 4.2.2. libsndfile worked for me with gcc 4.2.2 without problems. . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one
--- Comment #12 from sergstesh at yahoo dot com 2008-01-18 03:20 --- Regarding About the dependency on optimization level, signed integer overflow is undefined in C standard so its not a good idea to depend on it. What GCC does is exploiting this fact for optimizations which is fine. - I do not think this is fine. As end user I want to see my errors the same way at any optimization level. My expectations are that regardless of optimization level I'll get my program functioning the same way, but with different memory consumption/speed. I am not talking about out of bounds indices and possible reshuffling of variables in memory, I'm talking about arithmetic/logic expressions, i.e. printf(some_var=%g\n, some_var); should always print the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
[Bug c/34841] 'make check' of libsndfile-1.0.17 fails with gcc-4.2.2 -O2 optimization, OK with -O1 one
--- Comment #10 from sergstesh at yahoo dot com 2008-01-18 03:05 --- Ismail, the problem, as I see it, is not the failure itself, but rather dependency on optimization level. My point is that if the code is buggy WRT signedness, it should be the same way buggy for any level of optimization. What I and others see is that code behavior changes depending on optimization. I myself very much dislike comparison between signed and unsigned warnings and do not allow myself to produce such a code, but in this case the warnings might be a blessing in disguise because the possibly buggy 'libsndfile' code shows what looks to me a 'gcc' bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34841
[Bug target/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code
--- Comment #5 from sergstesh at yahoo dot com 2006-11-18 15:17 ---
IIRC, misaligned data should cause performance penalty, not segmentation fault.
Look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818 , at the case when
there is no segfault:
when the code runs fine (i.e. compiled by gcc-4.1.1), the screen output is:
checkpoint 1
inp_array_1[0]=80498e0
checkpoint 2
bn=1
inp_array_1[1]=80498e4
checkpoint 3
checkpoint 4
...
- as you see 'inp_array_1[1]=80498e4', and its WRT to line numbers 31..35 in:
29 while(half_nos - bn = NUMBER_OF_ELEMENTS_IN_VECTOR)
30 {
31 fprintf(stderr, bn=%u\n, bn);
32 fprintf(stderr, inp_array_1[%u]=%0lx\n, bn, (unsigned
long)inp_array_1[bn]);
33
34 fprintf(stderr, checkpoint 3\n);
35 vtmp1.v = *(vFloat *)inp_array_1[bn];
36 fprintf(stderr, checkpoint 4\n);
37
38 bn += NUMBER_OF_ELEMENTS_IN_VECTOR;
39 } // while(half_nos - bn = NUMBER_OF_ELEMENTS_IN_VECTOR)
.
In this case the address is 80498e4, i.e. no a multiple of 16, still, the
code does not segfault, even though a misaligned operation:
35 vtmp1.v = *(vFloat *)inp_array_1[bn];
is executed.
This is what I found in the documentation:
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options
:
-mpreferred-stack-boundary=num
Attempt to keep the stack boundary aligned to a 2 raised to num byte
boundary. If -mpreferred-stack-boundary is not specified, the default is 4 (16
bytes or 128 bits), except when optimizing for code size (-Os), in which case
the default is the minimum correct alignment (4 bytes for x86, and 8 bytes for
x86-64).
On Pentium and PentiumPro, double and long double values should be aligned
to an 8 byte boundary (see -malign-double) or suffer significant run time
performance penalties. On Pentium III, the Streaming SIMD Extension (SSE) data
type __m128 suffers similar penalties if it is not 16 byte aligned.
...
- from the above I expected to suffer significant run time performance
penalties, but not a segfault.
Could you please:
1) point me to the documentation which says that misaligned SSE data will
cause segfault;
2) if such a document does not exist, update the documentation, preferably
pointing also to Intel documentation stating that misaligned SSE data causes
segmentation fault;
3) explain, how/why the code in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
does not segfault even though it has the same misalignment as here
?
Thanks in advance.
--
sergstesh at yahoo dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #15 from sergstesh at yahoo dot com 2006-11-19 01:59 --- Is the alignment requirement always applicable in all the cases, or just for gcc-3.4.6 ? Remember, in this case gcc-4.1.1 produces code which doesn't segfault. Is it that gcc-4.1.1 optimizes out the failing line ? Is it that gcc-4.1.1 falsely aligns the memory location in question ? Is it that gcc-4.1.1 uses misaligned load into SSE registers by default ? Is there any page in gcc manual clearly saying: align your data properly or your program will segfault ? I am specifically interested in the or your program will segfault part ? -- sergstesh at yahoo dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #17 from sergstesh at yahoo dot com 2006-11-19 02:20 --- Regarding Is it that gcc-4.1.1 falsely aligns the memory location in question ? Well it can be 8byte aligned and accidently also 16byte aligned (which does happen every once in a while). The original report shows: inp_array_1[1]=80498e4 checkpoint 3 Segmentation fault , i.e. the failing address is not 8 bytes aligned, it's 4 bytes aligned. Regarding I am specifically interested in the or your program will segfault part ? This is call debugging your program. Also you really should read web pages about SSE programming because it seems like you don't understand how to use. I did read documentation on the issue, beginning from gcc manual. You correctly point out that by default aligned loads are used, which are faster, and Intel documentation says that misaligned address in such a case causes general protection fault. Which can be dealt with by kernel. The point is that I do not recall in the gcc manual mentioning of the default aligned load. Adding one sentence (if it's not yet there) would make life of both end users and developers easier - the developers will have to deal with smaller amount of bug reports like this one. Regarding Also using mode with vector mode is deprecated and you should be using vector_size instead. - sure, just gcc-3.4.6 doesn't understand this. I do not remember how the gcc version macro is called, so I used the code which was compatible with both gcc-3.4.6 and gcc-4.1.1, though it produces warning on gcc-4.1.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug c/29884] New: gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code
Hello, this bug is most likely related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818 , but now it's gcc-4.1.1, gcc-4.0.1, not gcc-3.4.6. Actually, it's the same code using which I discovered http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818 , just this is the full version of the code, not the shortened one. This bug was discovered while I was debugging the code and added a missing functional part. -- Summary: gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergstesh at yahoo dot com GCC build triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep 26 12:41 GCC host triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep 26 12:41 GCC target triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep 26 12:41 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884
[Bug c/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code
--- Comment #1 from sergstesh at yahoo dot com 2006-11-18 06:10 --- Created an attachment (id=12637) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12637action=view) the C file causing the failure If I run this file, it fails with: checkpoint 1 signal_spectrum_L[0]=80491e0 signal_spectrum_R[0]=8049140 checkpoint 2 half_number_of_samples=16 bin_number=1 bin_number=1 signal_spectrum_L[1]=80491e4 checkpoint 3 Segmentation fault . Which means that this: 102 v_r_signal_L.v = *(vFloat *)signal_spectrum_L[bin_number]; is the offending line. Please pay attention to these lines: 157 *(vFloat *)signal_spectrum_L[bin_number] = v_r_signal_L.v; 158 *(vFloat *)signal_spectrum_R[bin_number] = v_r_signal_R.v; 159 160 signal_spectrum_L[number_of_samples_minus_bin_number] = v_i_signal_L.f[0]; 161 signal_spectrum_R[number_of_samples_minus_bin_number] = v_i_signal_R.f[0]; 162 163 signal_spectrum_L[number_of_samples_minus_bin_number_minus_1] = v_i_signal_L.f[1]; 164 signal_spectrum_R[number_of_samples_minus_bin_number_minus_1] = v_i_signal_R.f[1]; 165 166 signal_spectrum_L[number_of_samples_minus_bin_number_minus_3] = v_i_signal_L.f[3]; 167 signal_spectrum_R[number_of_samples_minus_bin_number_minus_3] = v_i_signal_R.f[3]; - they are well below the offending line #102 in the same loop body, so at first site they shouldn't matter - segfaults occurs before them. Well, it's not the case, they do matter, if they are commented out, the segfault does not occur, the program completes normally. The above line #157..167 are the missing functional piece I discovered while debugging, it's writeback. I'll upload the .i files, as required, so you'll be able to compile the files and hopefully reproduce the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884
[Bug c/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code
--- Comment #2 from sergstesh at yahoo dot com 2006-11-18 06:15 --- Created an attachment (id=12638) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12638action=view) .i source causing segfault This is the .i file which causes segfault. Line #157..167 are not commented out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884
[Bug c/29884] gcc-4.1.1, gcc-4.0.1 generate segfaulting SSE code
--- Comment #3 from sergstesh at yahoo dot com 2006-11-18 06:18 --- Created an attachment (id=12639) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12639action=view) .i source file not causing segfault This is .i source file with line #157..167 commented out, and there is no segfault in this case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29884
[Bug rtl-optimization/29874] New: gcc-4.1.1 generates consistently worse performming SSE code than gcc-3.4.6
Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergstesh at yahoo dot com GCC build triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep 26 12:41 GCC host triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep 26 12:41 GCC target triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep 26 12:41 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29874
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #8 from sergstesh at yahoo dot com 2006-11-17 01:27 --- Please see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29874 - another proof that gcc-3.4.6 generates better SSE code than gcc-4.1.1, and the proof uses only widely available and well known GPL'ed code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #10 from sergstesh at yahoo dot com 2006-11-17 02:03 --- (In reply to comment #9) (In reply to comment #8) Please see Can you try the patch mentioned in: http://gcc.gnu.org/ml/gcc-patches/2006-11/msg01005.html (I am about to submit a new version of the patch but it does not change functionality of the patch, just some style issues). If that does not work, this is most likely an issue with unions and vector accesses which is really PR 28367. I am working slowly on these two issues because I have other work I need to do for Sony. I am confused. Is this patch supposed to fix segmentation fault described in this report, so the patch needs to be applied to gcc-3.4.6 OR this patch is supposed to improve performance of gcc-4.1.1 WRT SSE ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #13 from sergstesh at yahoo dot com 2006-11-17 02:23 --- (In reply to comment #11) I'm only a bug master and don't do any work on the compiler anyway, so my say isn't worth much, but here's my take: You propose that you can give us 15,000 lines of obfuscated code through which we will have to dig ourselves to find out what is causing the slowdown, and then fix the problem. At the same time you sit at the sidelines and wait for us to work on the code that you have purposefully made hard to read. What you apparently don't understand is that many of us work on gcc in our spare time. If you want us to do something for you, you will have to help us some. That might include trying to find out which part of the code slowed down, or to make the code significantly slower. Typically, the bug reports that come with the smallest testcases receive the most attention. You just have to realize that you don't pay us to do the crappy work of taking apart an obfuscated code. Since nobody pays us to work on random bug reports, we typically pick the ones that are the most interesting or that are the easiest to tackle since they come with a short testcase. We do have an interest in making gcc better, but we reserve the right to decide which parts of the compiler to make better, unless you pay someone to do some specific piece of work. I am simply saying I do not want to spend my time changing the code to be able to publish it if you are not going to deal with the performance issue anyway. We may. You can increase your chances by helping us. W. I opened another bug report, and mentioned it above, specifically devoted to the performance issue: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29874 . The example is based on FFTW, which is GPL - not a line of my code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug c/29818] New: code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
A (now pretty simple) piece of code segfaults when compiled with gcc-3.4.6, but runs fine with gcc-4.1.1. The offending line is: vtmp1.v = *(vFloat *)inp_array_1[bn]; -please wait until upload the source file. Both gcc-3.4.6 and gcc-4.1.1 were built by myself; the same code segfaults when compiled using stock Mandrivaa gcc-3.3.6 and runs fine when compiled using stock Mandriva gcc-4.0.1, so, I guess, it doesn't really matter how I built gcc-3.4.6 and gcc-4.1.1. Anyway, gcc-3.4.6 and gcc-4.1.1 were built using my http://appsfromscratch.berlios.de/ tool, I can send the log files showing pretty standard, except for local installation dir, configuration options. When the code fails (i.e. compiled by gcc-3.4.6), the screen output is: checkpoint 1 inp_array_1[0]=80498e0 checkpoint 2 bn=1 inp_array_1[1]=80498e4 checkpoint 3 Segmentation fault ; when the code runs fine (i.e. compiled by gcc-4.1.1), the screen output is: checkpoint 1 inp_array_1[0]=80498e0 checkpoint 2 bn=1 inp_array_1[1]=80498e4 checkpoint 3 checkpoint 4 bn=5 inp_array_1[5]=80498f4 checkpoint 3 checkpoint 4 bn=9 inp_array_1[9]=8049904 checkpoint 3 checkpoint 4 inp_array_1[0]=1 inp_array_1[1]=2 inp_array_1[2]=3 inp_array_1[3]=4 inp_array_1[4]=5 inp_array_1[5]=6 inp_array_1[6]=7 inp_array_1[7]=8 inp_array_1[8]=9 inp_array_1[9]=10 inp_array_1[10]=11 inp_array_1[11]=12 inp_array_1[12]=13 inp_array_1[13]=14 inp_array_1[14]=15 inp_array_1[15]=16 inp_array_1[16]=17 inp_array_1[17]=18 inp_array_1[18]=19 inp_array_1[19]=20 inp_array_1[20]=21 inp_array_1[21]=22 inp_array_1[22]=23 inp_array_1[23]=24 inp_array_1[24]=25 inp_array_1[25]=26 inp_array_1[26]=27 inp_array_1[27]=28 inp_array_1[28]=29 inp_array_1[29]=30 inp_array_1[30]=31 inp_array_1[31]=32 . The command line used for compilation: /AppsFromScratchWD/install/gcc-3.4.6/bin/gcc -save-temps -O2 -Wall -msse -mfpmath=sse -o sse_bug sse_bug.c . The command line used to run: ./sse_bug . -- Summary: code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1 Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergstesh at yahoo dot com GCC build triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep 26 12:41 GCC host triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep 26 12:41 GCC target triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB #1 Tue Sep 26 12:41 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug c/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #1 from sergstesh at yahoo dot com 2006-11-13 16:40 --- Created an attachment (id=12606) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12606action=view) source code which causes the segfault under gcc-3.4.6 and runs fine under gcc-4.1.1 The file is the result -save-temps command line option used during compilation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #3 from sergstesh at yahoo dot com 2006-11-14 01:04 --- (In reply to comment #2) You should note that 3.4.x is no longer being maintained so this bug will most likely be closed as fixed as you already mention it works in 4.1.1. That's too bad. I am developing pretty heavy SSE-based code, and performance-wise gcc-3.4.6 is the best so far. Sorry, I cant' post the code, but here are performance figures (output of 'time' command): with gcc-4.1.1 -O3: 567.341u 2.098s 9:35.75 98.9% 0+0k 0+0io 0pf+0w 567.055u 2.229s 9:37.18 98.6% 0+0k 0+0io 0pf+0w with gcc-3.4.6 -O2: 543.440u 2.038s 9:13.76 98.5% 0+0k 0+0io 0pf+0w 542.925u 2.149s 9:16.29 97.9% 0+0k 0+0io 0pf+0w . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #5 from sergstesh at yahoo dot com 2006-11-14 01:36 --- (In reply to comment #4) (In reply to comment #3) I am developing pretty heavy SSE-based code, and performance-wise gcc-3.4.6 is the best so far. Sorry, I cant' post the code, but here are performance figures (output of 'time' command): Then, you are not helping the project: a closed branch is not re-opened because of a bug and posting performance numbers without a *reduced* snippet pinpointing the specific issue is not useful to the developers (the only possible effect is making someone slightly nervous ;) The real piece of code I'm working on is 14923 lines long (the C file, not the i file). I can think of obfuscating it to the point it becomes not clear what it is doing functionally. We can make a deal: I obfuscate and publish the code, you guys fix the bug preserving, if possible, performance. The code is really complex, and it's not realistic for me to make it smaller. By the way, using gcc-3.4.6 with '-O3' makes performance much worse, worse than the one obtained with gcc-4.1.1. On the other hand, '-O3' applied to gcc-4.1.1 does not change the performance that drastic, though I do not remember at the moment whether the performance improves or deteriorates. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug target/29818] code with SSE segfaults with gcc-3.4.6, runs fine with gcc-4.1.1
--- Comment #7 from sergstesh at yahoo dot com 2006-11-14 02:54 --- (In reply to comment #6) (In reply to comment #5) We can make a deal: I obfuscate and publish the code, you guys fix the bug preserving, if possible, performance. The code is really complex, and it's not realistic for me to make it smaller. I guess our side of the deal would be: if you don't want to help us, we don't want to help you. You need to give us some more information to entice us to spend our leisure time on it. This is free software, after all. W. I don't quite understand what you want. Will it be enough if I give you the code which shows the above performance difference ? Are you interested to do the research and improvement ? I am simply saying I do not want to spend my time changing the code to be able to publish it if you are not going to deal with the performance issue anyway. I think it's common interest to have a well performing compiler, especially taking into account that the newer version performs somewhat worse than the older one. If you are talking about the size - believe me the code is really sensitive, that's why I am afraid to change it significantly. For example, initially there were parts organized like this: bunch_of_actions_of_type_A bunch_of_actions_of_type_B - it was easier to think of the implementation this way. Logically it was possible to interleave pieces of bunch_of_actions_of_type_A and bunch_of_actions_of_type_B, so I tried this change, and it improved performance. I tried other things like interleaved/separate buffers, but the result deteriorated. So, I am where am, and I'm afraid if I changed the code the performance phenomena would change with it. I probably can still make the code smaller - there are kind of unrolled by myself loops in it (but not quite, i.e. it's not only array elements in the unrolled pieces), so I can probably decrease the number of iterations. So, say, instead of 60 similar pieces in each portion you'll have 30 or 20 ones. But it will still be thousands of lines. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29818
[Bug testsuite/29760] 'make check' for gcc-3.4.6 fails
--- Comment #8 from sergstesh at yahoo dot com 2006-11-09 13:41 --- I looked into source code of 'test_summary' script and it indeed calls the 'Mail' program, the one with capital 'M'. I have never heard of it, I am familiar with 'mail' with small 'm'. On my system it's lrwxrwxrwx 1 root root 14 Jan 12 2006 /usr/bin/Mail - ../../bin/mail . Is it OK ? I tried ../gcc-3.4.6.src/contrib/test_summary -p /dev/null -m [EMAIL PROTECTED] -f | sh - pay attention to '-f', and nothing happens. No mail is sent, no messages on screen. How can I regenerate the Email text produced by the first invokation of 'test_summary' ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
[Bug testsuite/29761] 'make check' for gcc-4.1.1 fails
--- Comment #2 from sergstesh at yahoo dot com 2006-11-09 22:30 --- After using 'make -k check' I see much more failures that reported in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760 , i.e. in my environment gcc-4.1.1 test suite produces much more failures than gcc-3.4.6 test suite. Here are some quick stats: /maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1 grep 'of unexpected failures' make_-k_check.log # of unexpected failures5 # of unexpected failures1 # of unexpected failures1 # of unexpected failures150 ; [46] 0:23 [EMAIL PROTECTED]:/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1 grep FAIL: make_-k_check.log FAIL: gcc.dg/cleanup-10.c execution test FAIL: gcc.dg/cleanup-11.c execution test FAIL: gcc.dg/cleanup-8.c execution test FAIL: gcc.dg/cleanup-9.c execution test FAIL: gcc.dg/vect/pr20122.c scan-tree-dump-times vectorized 1 loops 2 FAIL: g++.old-deja/g++.law/weak.C (test for excess errors) FAIL: abi_check FAIL: libmudflap.c/fail1-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail10-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail11-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail12-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail13-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail14-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail15-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail16-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail17-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail18-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail19-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail2-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail20-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail21-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail22-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail23-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail25-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail26-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail27-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail28-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail29-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail3-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail30-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail31-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail32-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail33-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail34-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail35-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail36-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail37-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail38-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail39-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail4-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail40-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail5-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail6-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail7-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail8-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/fail9-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/heap-scalestress.c (-static) (test for excess errors) FAIL: libmudflap.c/hook-allocstuff.c (-static) (test for excess errors) FAIL: libmudflap.c/hook2-allocstuff.c (-static) (test for excess errors) FAIL: libmudflap.c/pass-stratcliff.c (-static) (test for excess errors) FAIL: libmudflap.c/pass1-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass1-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass10-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass10-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass11-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass11-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass12-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass12-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass13-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass13-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass14-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass14-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass15-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass15-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass16-frag.c (-static) (test for excess errors) FAIL: libmudflap.c/pass16-frag.c (-static) (test for excess
[Bug testsuite/29761] 'make check' for gcc-4.1.1 fails
--- Comment #4 from sergstesh at yahoo dot com 2006-11-09 23:01 --- Thanks for your reply. Regarding FAIL: g++.old-deja/g++.law/weak.C (test for excess errors) Unknown and you should look into g++.log. - you probably meant gcc/testsuite/g++/g++.log.sent file. If it's the case, here's what I've found: FAIL: g++.old-deja/g++.law/weak.C (test for excess errors) Excess errors: /usr/bin/ld: cannot find -lm . I think that the missing library is /usr/lib/libm.so which is present on my system. Is it so that 'gcc' test process doesn't look for libraries in standard places ? And if youy remember by heart, where can I downlaod sources of 'libm' from ? Regarding 'glibc' - what is the best compatible with gcc-4.1.1 version ? And why the number of failure so drastically differs between gcc-4.1.1 and gcc-3.6.4 ? 'glibc' is the same in both cases. Regarding 'glibc' - what is the best compatible with gcc-4.1.1 ? Is there a 'glibc' version which is good for both gcc-3.4.6 and gcc-4.1.1 ? If not, what is the best compatible with gcc-3.4.6 ? Based on your answers I'll try to build 'glibc' myself - if necessary, it will be two different versions for gcc-3.4.6 and gcc-4.1.1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29761
[Bug testsuite/29760] New: 'make check' for gcc-3.4.6 fails
/po'
make[2]: Nothing to be done for `check'.
make[2]: Leaving directory
`/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6/i686-pc-linux-gnu/libstdc++-v3/po'
Making check in testsuite
make[2]: Entering directory
`/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6/i686-pc-linux-gnu/libstdc++-v3/testsuite'
touch testsuite_wchar_t
make -j1 check-DEJAGNU
make[3]: Entering directory
`/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6/i686-pc-linux-gnu/libstdc++-v3/testsuite'
Making a new site.exp file...
srcdir=`CDPATH=${ZSH_VERSION+.}: cd
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/libstdc++-v3/testsuite
pwd`; export srcdir; \
EXPECT=expect; export EXPECT; \
runtest=runtest; \
if /bin/sh -c $runtest --version /dev/null 21; then \
l='libstdc++'; for tool in $l; do \
$runtest --tool $tool --srcdir $srcdir ; \
done; \
else echo WARNING: could not find \`runtest' 12; :;\
fi
WARNING: Couldn't find the global config file.
Test Run By sergei on Wed Nov 8 02:36:45 2006
Native configuration is i686-pc-linux-gnu
=== libstdc++ tests ===
Schedule of variations:
unix
Running target unix
Using
/maxtor5/sergei/AppsFromScratchWD/install/dejagnu-1.4.4/share/dejagnu/baseboards/unix.exp
as board description file for target.
Using
/maxtor5/sergei/AppsFromScratchWD/install/dejagnu-1.4.4/share/dejagnu/config/unix.exp
as generic interface file for target.
Using
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/libstdc++-v3/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/libstdc++-v3/testsuite/libstdc++-abi/abi.exp
...
FAIL: abi_check
Running
/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6.src/libstdc++-v3/testsuite/libstdc++-dg/normal.exp
...
XPASS: 22_locale/locale/cons/12658_thread.cc execution test
XPASS: 26_numerics/c99_classification_macros_c.cc (test for excess errors)
=== libstdc++ Summary ===
# of expected passes2736
# of unexpected failures1
# of unexpected successes 2
# of expected failures 5
make[3]: *** [check-DEJAGNU] Error 1
make[3]: Leaving directory
`/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6/i686-pc-linux-gnu/libstdc++-v3/testsuite'
make[2]: *** [check-am] Error 2
make[2]: Leaving directory
`/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6/i686-pc-linux-gnu/libstdc++-v3/testsuite'
make[1]: *** [check-recursive] Error 1
make[1]: Leaving directory
`/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6/i686-pc-linux-gnu/libstdc++-v3'
make: *** [check-target-libstdc++-v3] Error 2
.
The majority of tests pass.
Please let me know whether you need additional info.
--
Summary: 'make check' for gcc-3.4.6 fails
Product: gcc
Version: 3.4.6
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergstesh at yahoo dot com
GCC build triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB
GCC host triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB
GCC target triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
[Bug testsuite/29761] New: 'make check' for gcc-4.1.1 fails
This bug is similar to http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=WAITINGbug_status=ASSIGNEDbug_status=UNCONFIRMEDbug_status=REOPENEDemail1=sergstesh%40yahoo.comemailtype1=exactemailassigned_to1=1emailreporter1=1 , just the failure is different - here's how 'make check' screen output looks: make[1]: Entering directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1' make[2]: Entering directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1/fastjar' make[2]: Nothing to be done for `check'. make[2]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1/fastjar' make[2]: Entering directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1/fixincludes' autogen -T /maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1.src/fixincludes/check.tpl /maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1.src/fixincludes/inclhack.def /bin/sh ./check.sh /maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1.src/fixincludes/tests/base Fixed: testing.h Fixed: testing.h Fixed: ansi/math.h Fixed: ansi/stdlib.h Fixed: arch/i960/archI960.h Fixed: arpa/inet.h Fixed: assert.h Fixed: AvailabilityMacros.h Fixed: bits/huge_val.h Fixed: bsd/libc.h Fixed: c_asm.h Fixed: com_err.h Fixed: ctrl-quotes-def-1.h Fixed: ctype.h Fixed: curses.h Fixed: fixinc-test-limits.h Fixed: fs/rfs/rf_cache.h Fixed: _G_config.h Fixed: hsfs/hsfs_spec.h Fixed: ia64/sys/getppdp.h Fixed: internal/math_core.h Fixed: internal/sgimacros.h Fixed: internal/wchar_core.h Fixed: inttypes.h Fixed: io-quotes-def-1.h Fixed: iso/math_c99.h Fixed: locale.h Fixed: machine/cpu.h Fixed: mach-o/dyld.h Fixed: malloc.h Fixed: math.h Fixed: netdnet/dnetdb.h Fixed: netinet/in.h Fixed: netinet/ip.h Fixed: obstack.h Fixed: pixrect/memvar.h Fixed: pthread.h Fixed: regex.h Fixed: regexp.h Fixed: reg_types.h Fixed: rpc/auth.h Fixed: rpc/rpc.h Fixed: rpc/svc.h Fixed: rpcsvc/rstat.h Fixed: rpcsvc/rusers.h Fixed: rpc/xdr.h Fixed: sparc/asm_linkage.h Fixed: standards.h Fixed: stdio.h Fixed: stdio_tag.h Fixed: stdlib.h Fixed: string.h Fixed: strings.h Fixed: sundev/vuid_event.h Fixed: sunwindow/win_lock.h Fixed: sym.h Fixed: sys/asm.h Fixed: sys/cdefs.h Fixed: sys/file.h Fixed: sys/ioctl.h Fixed: sys/limits.h Fixed: sys/machine.h Fixed: sys/mman.h Fixed: sys/regset.h Fixed: sys/signal.h Fixed: sys/socket.h Fixed: sys/spinlock.h Fixed: sys/stat.h Fixed: sys/time.h Fixed: sys/times.h Fixed: sys/types.h Fixed: sys/ucontext.h Fixed: sys/utsname.h Fixed: sys/wait.h Fixed: testing.h Fixed: time.h Fixed: tinfo.h Fixed: types/vxTypesBase.h Fixed: unistd.h Fixed: wchar.h Fixed: widec.h Fixed: X11/ShellP.h Fixed: X11/Xmu.h Fixed: Xm/BaseClassI.h Fixed: Xm/Traversal.h Newly fixed header: ia64/sys/getppdp.h There were fixinclude test FAILURES make[2]: *** [check] Error 1 make[2]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1/fixincludes' make[1]: *** [check-fixincludes] Error 2 make[1]: Leaving directory `/maxtor5/sergei/AppsFromScratchWD/build/gcc-4.1.1' make: *** [do-check] Error 2 . 'autogen-2.60' was used. It appears that, unlike in http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=NEWbug_status=WAITINGbug_status=ASSIGNEDbug_status=UNCONFIRMEDbug_status=REOPENEDemail1=sergstesh%40yahoo.comemailtype1=exactemailassigned_to1=1emailreporter1=1 no test is run, 'make check' aborts due to some problem during fixing headers. Please let me know whther you need any additional info. -- Summary: 'make check' for gcc-4.1.1 fails Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sergstesh at yahoo dot com GCC build triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB GCC host triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB GCC target triplet: Linux comp.home.net 2.6.12-27mdk-i686-up-4GB http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29761
[Bug testsuite/29760] 'make check' for gcc-3.4.6 fails
--- Comment #2 from sergstesh at yahoo dot com 2006-11-08 21:44 --- I do not understand you comment. That is, from 'make' manpage: -k Continue as much as possible after an error. While the target that failed, and those that depend on it, cannot be remade, the other dependencies of these targets can be processed all the same. - my point was that there were failing tests. And my implied questions were: 1) do the failing tests indicate problems in gcc ? 2) do the failing test fail because they themselves are faulty ? After 'make check': FAIL: gcc.c-torture/execute/va-arg-25.c execution, -Os FAIL: gcc.dg/cleanup-8.c execution test FAIL: gcc.dg/cleanup-9.c execution test FAIL: gcc.dg/special/gcsec-1.c (test for excess errors) FAIL: g++.old-deja/g++.law/weak.C (test for excess errors) FAIL: abi_check . After 'make -k check': FAIL: gcc.c-torture/execute/va-arg-25.c execution, -Os FAIL: gcc.dg/cleanup-8.c execution test FAIL: gcc.dg/cleanup-9.c execution test FAIL: gcc.dg/special/gcsec-1.c (test for excess errors) FAIL: g++.old-deja/g++.law/weak.C (test for excess errors) FAIL: abi_check FAIL: gctest . Could you please answer the: 1) do the failing tests indicate problems in gcc ? 2) do the failing test fail because they themselves are faulty ? questions ? Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
[Bug testsuite/29760] 'make check' for gcc-3.4.6 fails
--- Comment #4 from sergstesh at yahoo dot com 2006-11-08 22:43 --- I read the document: http://gcc.gnu.org/install/test.html, but it doesn't answer my questions. If you need test results reported through the suggested srcdir/contrib/test_summary -p your_commentary.txt \ -m [EMAIL PROTECTED] |sh command, I can do this, but will you answer the 1) do the failing tests indicate problems in gcc ? 2) do the failing test fail because they themselves are faulty ? questions ? If not, why should I bother in the first place ? If yes, what info other than the one produced by srcdir/contrib/test_summary -p your_commentary.txt \ -m [EMAIL PROTECTED] |sh do you need ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
[Bug testsuite/29760] 'make check' for gcc-3.4.6 fails
--- Comment #7 from sergstesh at yahoo dot com 2006-11-08 23:29 --- OK, being in /maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6 directory, which is my 'obj' directory, I tried to run the 'test_summary' mentioned at the bottom of http://gcc.gnu.org/install/test.html : 0.5 Submitting test results If you want to report the results to the GCC project, use the contrib/test_summary shell script. Start it in the objdir with srcdir/contrib/test_summary -p your_commentary.txt \ -m [EMAIL PROTECTED] |sh This script uses the Mail program to send the results, so make sure it is in your PATH. The file your_commentary.txt is prepended to the testsuite summary and should contain any special remarks you have on your results or your build environment. Please do not edit the testsuite result block or the subject line, as these messages may be automatically processed. . Please pay attention to This script uses the Mail program to send the results, so make sure it is in your PATH . On my system: [21] 1:20 [EMAIL PROTECTED]:/maxtor5/sergei/AppsFromScratchWD/build/gcc-3.4.6 which mail /bin/mail . However, here's what I'm getting running the program: ../gcc-3.4.6.src/contrib/test_summary -p /dev/null -m [EMAIL PROTECTED] | sh /usr/sbin/sendmail: No such file or directory /ibm/home/sergei/dead.letter 103/2351 . . . message not sent. . So, should I file a bug against http://gcc.gnu.org/install/test.html because of 'mail' - /usr/sbin/sendmail discrepancy ? Anyway, I looked into /ibm/home/sergei/dead.letter file and it contains pretty much the same info I've already posted. If you insist, I can install /usr/sbin/sendmail and try again. Maybe you already have enough info to tell me which of the tests fail due to: 1) problems in the compiler; 2) problems in glibc; 3) problems in the tests themselves ? Thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29760
