RE: A gcc-cris bug?

["Dave Korn" <dk at artimi dot com>]

> -----Original Message-----
> From: gcc-owner On Behalf Of Tal Agmon
> Sent: 06 October 2004 12:31
> To: Richard Guenther

> Richard Guenther wrote:
> > Tal Agmon wrote:
> >> The output should be:
> >> 
> >> foo is: 0, i is: 0
> 
> >no, it clearly should be
> 
> >foo is: 0, i is: 1
> 
> >Richard.
> 
> Sorry, you are right, the write output is foo is: 0, i is: 1. 
> But I believe that gcc-3.4.2, target=cris, -O3 option enable, 
> will produce an infinite loop!
> 
> Furthermore, the wrong output that I provided was copied from 
> running this test on gcc-3.4.2 on i686-pc-linux-gnu.
 
  I can confirm the same bad output on cygwin 3.3.3.  It also takes a
ridiculous amount of time to execute.

dk@mace /artimi> cat foo.c
#include <stdio.h>
int foo=100;

int f ()
{
  foo = 0;
}

void main ()
{
  int i;

  for (i = 0; i < foo; i++)
    {
      f ();
    }
  printf("foo is: %d, i is: %d\n",foo,i);
}
dk@mace /artimi> gcc -v
Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.3/specs
Configured with: /gcc/gcc-3.3.3-3/configure --verbose --prefix=/usr
--exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-languages=c,ada,c++,d,f77,java,objc,pascal --enable-nls
--without-included-gettext --enable-libgcj --with-system-zlib
--enable-interpreter --enable-threads=posix --enable-java-gc=boehm
--enable-sjlj-exceptions --disable-version-specific-runtime-libs
--disable-win32-registry
Thread model: posix
gcc version 3.3.3 (cygwin special)
dk@mace /artimi> gcc -g -O3 foo.c -o foo
foo.c: In function `main':
foo.c:10: warning: return type of `main' is not `int'
dk@mace /artimi> ./foo.exe
foo is: 0, i is: 0
dk@mace /artimi> time ./foo.exe
foo is: 0, i is: 0

real    0m3.370s
user    0m3.343s
sys     0m0.015s
dk@mace /artimi>

  Taking a look at the source:

.globl _main
	.def	_main;	.scl	2;	.type	32;	.endef
_main:
	pushl	%ebp
	movl	%esp, %ebp
	subl	$24, %esp
	andl	$-16, %esp
	xorl	%eax, %eax
	call	__alloca
	call	___main
	xorl	%edx, %edx
	movl	_foo, %eax
	cmpl	%eax, %edx
	jge	L9
	.p2align 4,,15
L7:
	xorl	%ecx, %ecx
	movl	%ecx, _foo
	decl	%edx
	jne	L7
	xorl	%eax, %eax
L9:
	movl	%edx, 8(%esp)
	movl	%eax, 4(%esp)
	movl	$LC0, (%esp)
	call	_printf
	xorl	%eax, %eax
	leave
	ret
	.p2align 4,,15

  It appears to have inlined the call to f () into the loop in main (), but
it's not realised that the loop test depends on a variable that might be
clobbered, and it's attempted to invert the loop and turned it into a count
down.  Whattamess!


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....