GCC 4.5 regression

GCC 4.5 regression

[Guy Martin]

[-- Attachment #1: Type: text/plain, Size: 3132 bytes --]


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

[-- Attachment #2: conftest.c --]
[-- Type: text/x-c++src, Size: 164 bytes --]

#include <unistd.h>

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

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


[-- Attachment #3: conftest-4.5.s --]
[-- Type: application/octet-stream, Size: 471 bytes --]

	.LEVEL 1.1
	.text
	.align 4
	.type	recurse.clone.0, @function
recurse.clone.0:
	.PROC
	.CALLINFO FRAME=0,NO_CALLS
	.ENTRY
.L2:
	b,n .L2
	.EXIT
	.PROCEND
	.size	recurse.clone.0, .-recurse.clone.0
	.align 4
.globl main
	.type	main, @function
main:
	.PROC
	.CALLINFO FRAME=0,NO_CALLS,SAVE_RP
	.ENTRY
	stw %r2,-20(%r30)
	ldi 1,%r26
	ldw -20(%r30),%r2
	bl recurse.clone.0,%r0
	nop
	nop
	.EXIT
	.PROCEND
	.size	main, .-main
	.ident	"GCC: (Gentoo 4.5.2 p1.0, pie-0.4.5) 4.5.2"

[-- Attachment #4: conftest-4.4.s --]
[-- Type: application/octet-stream, Size: 725 bytes --]

	.LEVEL 1.1
	.text
	.align 4
	.type	recurse, @function
recurse:
	.PROC
	.CALLINFO FRAME=576,CALLS,SAVE_RP
	.ENTRY
	stw %r2,-20(%r30)
	ldb 0(%r26),%r28
	ldo 1(%r28),%r28
	ldo 576(%r30),%r30
	stb %r28,-568(%r30)
	bl recurse,%r2
	ldo -568(%r30),%r26
	ldw -596(%r30),%r2
	bv %r0(%r2)
	ldo -576(%r30),%r30
	.EXIT
	.PROCEND
	.size	recurse, .-recurse
	.section	.rodata.str1.4,"aMS",@progbits,1
	.align 4
.LC0:
	.stringz	"\001"
	.text
	.align 4
.globl main
	.type	main, @function
main:
	.PROC
	.CALLINFO FRAME=0,NO_CALLS,SAVE_RP
	.ENTRY
	stw %r2,-20(%r30)
	ldil LR'.LC0,%r26
	ldw -20(%r30),%r2
	ldo RR'.LC0(%r26),%r26
	bl recurse,%r0
	nop
	nop
	.EXIT
	.PROCEND
	.size	main, .-main
	.ident	"GCC: (Gentoo 4.4.5 p1.2, pie-0.4.5) 4.4.5"

Re: GCC 4.5 regression

[John David Anglin]

On Thu, 17 Feb 2011, Guy Martin wrote:

> 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 ?

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                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)

Re: GCC 4.5 regression

[Matt Turner]

On Thu, Feb 17, 2011 at 7:15 PM, Guy Martin <gmsoft@tuxicoman.be> wrote:
> 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.

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

Re: GCC 4.5 regression

[Mike Frysinger]

On Thu, Feb 17, 2011 at 8:28 PM, Matt Turner wrote:
> On Thu, Feb 17, 2011 at 7:15 PM, Guy Martin wrote:
>> 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.
>
> 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.

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

Re: GCC 4.5 regression

[Guy Martin]

> > 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? :)

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

> >
> > 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.
>
> 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

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