[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2

[sergstesh at yahoo dot com]

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.