This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
gcc-4.8 + tree-loop-distribute-patterns breaks glibc-2.18
- From: "Winfried Magerl" <winfried dot magerl at t-online dot de>
- To: gcc at gcc dot gnu dot org
- Cc: libc-alpha at sourceware dot org
- Date: Mon, 20 May 2013 14:03:04 +0200
- Subject: gcc-4.8 + tree-loop-distribute-patterns breaks glibc-2.18
Hi,
I've tried to compile upcoming glibc-2.18 with gcc-4.8.x and optimized
with '-O3' and testsuite breaks horrible with SIGSEGV and eating up
all available memory.
I've tracked it down to the flag 'tree-loop-distribute-patterns' and can
reproduce the problem with CFLAGS='-g -O2 -ftree-loop-distribute-patterns'
on my own system and on clean openSUSE 12.3 (x86_64) with gcc-4.8.1-20130519.
System:
AMD FX(tm)-6300 Six-Core Processor (fam: 15, model: 02, stepping: 00)
linux-3.9.3
gcc (GCC) 4.8.1 20130519
binutils-2.23.52.0.2
glibc-repository is from 20130519.
I've done some more checks on the first failing test 'csu/tst-atomic' which
is the second test in the test-suite:
env GCONV_PATH=/home/winfried/glibc-cvs/winni/iconvdata LC_ALL=C /home/winfried/glibc-cvs/winni/elf/ld-linux-x86-64.so.2 --library-path /home/winfried/glibc-cvs/winni:/home/winfried/glibc-cvs/winni/math:/home/winfried/glibc-cvs/winni/elf:/home/winfried/glibc-cvs/winni/dlfcn:/home/winfried/glibc-cvs/winni/nss:/home/winfried/glibc-cvs/winni/nis:/home/winfried/glibc-cvs/winni/rt:/home/winfried/glibc-cvs/winni/resolv:/home/winfried/glibc-cvs/winni/crypt:/home/winfried/glibc-cvs/winni/nptl /home/winfried/glibc-cvs/winni/csu/tst-atomic
gdb-output:
# gdb /home/winfried/glibc-cvs/winni/elf/ld-linux-x86-64.so.2 core
[.........]
Reading symbols from /home/winfried/glibc-cvs/winni/elf/ld-linux-x86-64.so.2...done.
warning: core file may not match specified executable file.
[New LWP 28667]
Core was generated by `/home/winfried/glibc-cvs/winni/elf/ld-linux-x86-64.so.2 --library-path /home/wi'.
Program terminated with signal 11, Segmentation fault.
#0 0x00007f92a16785c4 in memset (dstpp=0x7fff51ca40c0, c=<optimized out>, len=6) at ../string/memset.c:81
81 while (len > 0)
(gdb) where
#0 0x00007f92a16785c4 in memset (dstpp=0x7fff51ca40c0, c=<optimized out>, len=6) at ../string/memset.c:81
#1 0x00007f92a16785c9 in memset (dstpp=0x7fff51ca40c0, c=<optimized out>, len=<optimized out>) at ../string/memset.c:81
#2 0x00007f92a16785c9 in memset (dstpp=0x7fff51ca40c0, c=<optimized out>, len=<optimized out>) at ../string/memset.c:81
#3 0x00007f92a16785c9 in memset (dstpp=0x7fff51ca40c0, c=<optimized out>, len=<optimized out>) at ../string/memset.c:81
[.....]
#75638 0x00007f92a16785c9 in memset (dstpp=0x7fff51ca40c0, c=<optimized out>, len=<optimized out>) at ../string/memset.c:81
#75639 0x00007f92a16785c9 in memset (dstpp=0x7fff51ca40c0, c=<optimized out>, len=<optimized out>) at ../string/memset.c:81
#75640 0x00007f92a16785c9 in memset (dstpp=0x7fff51ca40c0, c=<optimized out>, len=<optimized out>) at ../string/memset.c:81
[.....]
some more notes:
- no problem with '-O3' and glibc-2.17
- no problem with gcc-4.7.3 and glibc-2.18
- CFLAGS for test-suite doesn't matter
I send this mail to gcc@gcc.gnu.org and libc-alpha@sourceware.org because
it's not obvious if it's a bug in glibc or in gcc.
I can help with testing but I'm not realy able to track this problem
down.
regards
winfried