GCC 4.5 regression

Hi all,

I've spotted this regression while testing gcc 4.5.2. It hangs while doing one of the configure test of diffutils.

I've attached a reduced test case. The program is supposed to segfault because of a stack overflow. However, with 4.5, it just hangs. It seems that 4.5 simply over-optimize the function and replaces it with a single jump.

Should I open a PR ?
Do you need other info ?

Here is how gcc is configured :

terminator test # gcc-4.4.5 -v
Using built-in specs.
Target: hppa2.0-unknown-linux-gnu
Configured
with: /var/tmp/portage/sys-devel/gcc-4.4.5/work/gcc-4.4.5/configure --prefix=/usr --bindir=/usr/hppa2.0-unknown-linux-gnu/gcc-bin/4.4.5 --includedir=/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.4.5/include --datadir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/4.4.5 --mandir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/4.4.5/man --infodir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/4.4.5/info --with-gxx-include-dir=/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.4.5/include/g++-v4 --host=hppa2.0-unknown-linux-gnu --build=hppa2.0-unknown-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/hppa2.0-unknown-linux-gnu/4.4.5/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.4.5 p1.2, pie-0.4.5' Thread model: posix gcc version 4.4.5 (Gentoo 4.4.5 p1.2, pie-0.4.5)

terminator test # gcc-4.5.2 -v
Using built-in specs.
COLLECT_GCC=gcc-4.5.2 COLLECT_LTO_WRAPPER=/usr/libexec/gcc/hppa2.0-unknown-linux-gnu/4.5.2/lto-wrapper
Target: hppa2.0-unknown-linux-gnu
Configured
with: /var/tmp/portage/sys-devel/gcc-4.5.2/work/gcc-4.5.2/configure --prefix=/usr --bindir=/usr/hppa2.0-unknown-linux-gnu/gcc-bin/4.5.2 --includedir=/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.2/include --datadir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/4.5.2 --mandir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/4.5.2/man --infodir=/usr/share/gcc-data/hppa2.0-unknown-linux-gnu/4.5.2/info --with-gxx-include-dir=/usr/lib/gcc/hppa2.0-unknown-linux-gnu/4.5.2/include/g++-v4 --host=hppa2.0-unknown-linux-gnu --build=hppa2.0-unknown-linux-gnu --disable-altivec --disable-fixed-point --without-ppl --without-cloog --disable-lto --enable-nls --without-included-gettext --with-system-zlib --disable-werror --enable-secureplt --disable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --enable-cld --with-python-dir=/share/gcc-data/hppa2.0-unknown-linux-gnu/4.5.2/python --enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.5.2 p1.0, pie-0.4.5' Thread model: posix gcc version 4.5.2 (Gentoo 4.5.2 p1.0, pie-0.4.5)

Cheers,
Guy

#include <unistd.h>

static int recurse (char *a)
{
char tmp[500];
*tmp = *a + 1;
return recurse(tmp);
}

int main (void) {
return recurse ("\1");
}

My sense is the test is wrong and the optimization is correct.

Optimizations such as this are done at the tree and rtl level. For the most part, backends do not perform loop optimizations. So, if you think the generated code is incorrect based on the C standard, then a PR should be opened.

There are quite a few '-f' options that affect optimization behavior. So, you may be able to disable loop optimizations and restore the previous behavior.

There may be a newer autoconf test available.

Dave

J. David Anglin                                  [email protected]
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

http://bugs.gentoo.org/show_bug.cgi?id=340923

It's known and fixed. It's not a gcc regression, nor is it HPPA-specific (didn't you try to confirm that it was HPPA-specific? :)

The reason you're hitting it is that you've keyworded gcc-4.5.2, but aren't running a full ~hppa system. vapier doesn't seem to acknowledge that this is a reasonable, sensible, or even common configuration.

Anyway, false alarm.

Matt

that's because it is not. there's a difference between running brand new bleeding edge versions of the toolchain on a stable system all the time and running them for the stabilization process. inevitably every gcc/glibc/kernel header upgrade in ~arch breaks a shit ton of stable packages (and even unstable packages), the vast majority of which will be fixed by those packages stabilizing a new version as natural progression by the time the toolchain versions have settled for stabilization.
-mike

My mistake. I hardly come accross non-hppa specific bugs :)

Kinda makes sens but it's probably not the right list to discuss.

In any case, thanks everybody for the feedback. I'm quite happy this is not a gcc issue !

Guy