the attached code from the diffutils configure script is supposed to check for "working C stack overflow detection" but instead hangs when built with trunk at -O2 or higher. 4.4.2 works. $ gcc -v Using built-in specs. COLLECT_GCC=/usr/x86_64-unknown-linux-gnu/gcc-bin/4.5.0-pre9999/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0-pre9999/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.5.0_pre9999/work/gcc-4.5.0-9999/configure --prefix=/usr --bindir=/usr/x86_64-unknown-linux-gnu/gcc-bin/4.5.0-pre9999 --includedir=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre9999/include --datadir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre9999 --mandir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre9999/man --infodir=/usr/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre9999/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0-pre9999/include/g++-v4 --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --disable-altivec --disable-fixed-point --with-ppl --with-cloog --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --enable-multilib --disable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/x86_64-unknown-linux-gnu/4.5.0-pre9999/python --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo SVN' --enable-lto --enable-checking Thread model: posix gcc version 4.5.0-pre9999 20091215 (experimental) rev. 155245 (Gentoo SVN)
Created attachment 19303 [details] conftest.i
Created attachment 19304 [details] conftest.c
This is a bug in the test. Early inter-procedural SRA avoids passing array by reference in the recurse() function and instead passes the first element which is the only one read. Thus the function is optimized to an endless loop. static int recurse (char *p) { char array[500]; array[0] = 1; return *p + recurse (array); } int main (void) { return recurse ("\1"); } on i686 (or with -m32) this does not happen - Martin, any idea why?
(In reply to comment #3) > > on i686 (or with -m32) this does not happen - Martin, any idea why? > I had to examine the testcase to find out. It turns out that on i686 is_va_list_type() returns true for this type (char *) and so IPA-SRA does not even consider it a candidate. The test was added because of premature decomposition of alpha stdarg structures (pretty much the same issue as with early intraprocedural SRA) and so does not really make sense here. An easy way out of this would be to allow scalar is_va_list_type types. I will make a patch for next stage 1.
...and I did that long time ago in revision 158057.