A gcc-cris bug?

A gcc-cris bug?

[Tal Agmon]

Hi,

Can someone please check the following test on gcc-3.4.2, target=cris, 
using -O3?
I believe it will expose a gcc bug.
Currently it produces a bug on the crx architecture which is not an 
official part
of gcc, I don't have the full cris toolchain but I created the compiler 
and I see
a similar problem gets reproduced. 

The source code is:
------------------------------------------------------
#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);
}
------------------------------------------------------
The output should be:

foo is: 0, i is: 0

Regards,
      Tal Agmon

Software Engineer                          phone: +49-8141-35-1396
CompactRISC Development Tools  fax:        fax:   +49-8141-35-11-1396
National Semiconductor GmbH              mailto:Tal.Agmon@nsc.com
Livry-Gargan Str. 10                       internet: 
http://www.national.com
82256 Fuerstenfeldbruck, Germany

Re: A gcc-cris bug?

[Richard Guenther]

On Wed, 6 Oct 2004 12:15:27 +0200, Tal Agmon <tal.agmon@nsc.com> wrote:

> The source code is:
> ------------------------------------------------------
> #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);
> }
> ------------------------------------------------------
> The output should be:
> 
> foo is: 0, i is: 0

no, it clearly should be

foo is: 0, i is: 1

Richard.

Re: A gcc-cris bug?

[Tal Agmon]

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.

RE: A gcc-cris bug?

[Dave Korn]

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

Re: A gcc-cris bug?

[Andrew Pinski]

On Oct 6, 2004, at 7:45 AM, Dave Korn wrote:

> #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);
> }

But the mainline at -O3 produces great code aka no loops at all:
;; Function main (main)

main ()
{
   int i;
   int foo.0;

<bb 0>:
   foo.0 = foo;
   if (foo.0 > 0) goto <L0>; else goto <L7>;

<L7>:;
   i = 0;
   goto <bb 2> (<L2>);

<L0>:;
   foo = 0;
   i = 1;
   foo.0 = 0;

<L2>:;
   printf (&"foo is: %d, i is: %d\n"[0], foo.0, i) [tail call];
   return;

}

Thanks,
Andrew Pinski

RE: A gcc-cris bug?

[Diego Novillo]

On Wed, 2004-10-06 at 07:45, Dave Korn wrote:

> dk@mace /artimi> time ./foo.exe
> foo is: 0, i is: 0
> 
> real    0m3.370s
> user    0m3.343s
> sys     0m0.015s
> dk@mace /artimi>
> 
Apparently fixed in mainline:

$ time ./a
foo is: 0, i is: 1

real    0m0.002s
user    0m0.001s
sys     0m0.001s


Diego.

RE: A gcc-cris bug?

[Dave Korn]

> -----Original Message-----
> From: Diego Novillo 
> Sent: 06 October 2004 13:03

> On Wed, 2004-10-06 at 07:45, Dave Korn wrote:
> 
> > dk@mace /artimi> time ./foo.exe
> > foo is: 0, i is: 0
> > 
> > real    0m3.370s
> > user    0m3.343s
> > sys     0m0.015s
> > dk@mace /artimi>
> > 
> Apparently fixed in mainline:
> 
> $ time ./a
> foo is: 0, i is: 1
> 
> real    0m0.002s
> user    0m0.001s
> sys     0m0.001s

  Heh, yeh, I was able to infer from Andrew's source listing that it wasn't
going to take long to execute! :)

  Hmm.  Bad timing in the release cycle to bring this up though.  Might be
worth looking at in time for 3.3.6, though, would be nice to knock it on the
head before the branch gets closed.


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

Re: A gcc-cris bug?

[Richard Guenther]

>   Heh, yeh, I was able to infer from Andrew's source listing that it wasn't
> going to take long to execute! :)
> 
>   Hmm.  Bad timing in the release cycle to bring this up though.  Might be
> worth looking at in time for 3.3.6, though, would be nice to knock it on the
> head before the branch gets closed.

Might be not a regression.  2.95.2 and 3.0 behave the same, i.e. use
-O2 -finline-functions,
or simpler put an inline before f.  Somebody should file a PR, though.

Richard.

Re: A gcc-cris bug?

[Andrew Pinski]

On Oct 6, 2004, at 8:48 AM, Richard Guenther wrote:

>>   Heh, yeh, I was able to infer from Andrew's source listing that it 
>> wasn't
>> going to take long to execute! :)
>>
>>   Hmm.  Bad timing in the release cycle to bring this up though.  
>> Might be
>> worth looking at in time for 3.3.6, though, would be nice to knock it 
>> on the
>> head before the branch gets closed.
>
> Might be not a regression.  2.95.2 and 3.0 behave the same, i.e. use
> -O2 -finline-functions,
> or simpler put an inline before f.  Somebody should file a PR, though.

Why it is fixed on the mainline already and for a good reason.  The
RTL optimizations were just not good.  The tree level ones is where
something like this gets fixed which is what happened, DOM (really
only the copy progation part) and copy loop headers fixed the problem.
There are many more places where things are fixed on the mainline for
4.0.0 which cannot be back ported to 3.x or 2.x.

-- Pinski

Re: A gcc-cris bug?

[Tal Agmon]

Andrew Pinski wrote:

> Why it is fixed on the mainline already and for a good reason.  The
> RTL optimizations were just not good.  The tree level ones is where
> something like this gets fixed which is what happened, DOM (really
> only the copy progation part) and copy loop headers fixed the problem.
> There are many more places where things are fixed on the mainline for
> 4.0.0 which cannot be back ported to 3.x or 2.x.

If I understand you right, gcc-3.4.* final version will be releases with 
this 
bug. Do you have a workaround recommended for gcc-3.4.* users?

Re: A gcc-cris bug?

[Richard Guenther]

On Wed, 6 Oct 2004 15:13:03 +0200, Tal Agmon <tal.agmon@nsc.com> wrote:
> Andrew Pinski wrote:
> 
> > Why it is fixed on the mainline already and for a good reason.  The
> > RTL optimizations were just not good.  The tree level ones is where
> > something like this gets fixed which is what happened, DOM (really
> > only the copy progation part) and copy loop headers fixed the problem.
> > There are many more places where things are fixed on the mainline for
> > 4.0.0 which cannot be back ported to 3.x or 2.x.
> 
> If I understand you right, gcc-3.4.* final version will be releases with
> this
> bug. Do you have a workaround recommended for gcc-3.4.* users?

Put __attribute__((noinline)) on the function f().

Richard.

Re: A gcc-cris bug?

[Daniel Jacobowitz]

On Wed, Oct 06, 2004 at 08:55:08AM -0400, Andrew Pinski wrote:
> 
> On Oct 6, 2004, at 8:48 AM, Richard Guenther wrote:
> 
> >>  Heh, yeh, I was able to infer from Andrew's source listing that it 
> >>wasn't
> >>going to take long to execute! :)
> >>
> >>  Hmm.  Bad timing in the release cycle to bring this up though.  
> >>Might be
> >>worth looking at in time for 3.3.6, though, would be nice to knock it 
> >>on the
> >>head before the branch gets closed.
> >
> >Might be not a regression.  2.95.2 and 3.0 behave the same, i.e. use
> >-O2 -finline-functions,
> >or simpler put an inline before f.  Somebody should file a PR, though.
> 
> Why it is fixed on the mainline already and for a good reason.  The
> RTL optimizations were just not good.  The tree level ones is where
> something like this gets fixed which is what happened, DOM (really
> only the copy progation part) and copy loop headers fixed the problem.
> There are many more places where things are fixed on the mainline for
> 4.0.0 which cannot be back ported to 3.x or 2.x.

But, thanks to our abject lack of unit testing, there is no way to see
if the problem still exists in 4.0.0.  Experience suggests that it
does, and will need a much more complicated testcase (to get through
the tree optimizers to whatever RTL optimizer is buggy).

-- 
Daniel Jacobowitz

Re: A gcc-cris bug?

[Richard Guenther]

> But, thanks to our abject lack of unit testing, there is no way to see
> if the problem still exists in 4.0.0.  Experience suggests that it
> does, and will need a much more complicated testcase (to get through
> the tree optimizers to whatever RTL optimizer is buggy).

One way of doing this is to analyze and fix the problem for 3.4 and
then possibly forward-port the fix.  But it ain't a regression...

Richard.

RE: A gcc-cris bug?

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Richard Guenther
> Sent: 06 October 2004 14:57
> To: Andrew Pinski; Richard Guenther; gcc; Dave 
> Korn; Diego Novillo; Tal Agmon
> Subject: Re: A gcc-cris bug?
> 
> > But, thanks to our abject lack of unit testing, there is no 
> way to see
> > if the problem still exists in 4.0.0.  Experience suggests that it
> > does, and will need a much more complicated testcase (to get through
> > the tree optimizers to whatever RTL optimizer is buggy).
> 
> One way of doing this is to analyze and fix the problem for 3.4 and
> then possibly forward-port the fix.  But it ain't a regression...
> 
> Richard.


  Maybe, but it does make -O3 unusable, doesn't it?  I know it's meant to be
'unsafe' and come with suitable health warnings, but this sort of bad
codegen just seems beyond coping with.  If the tree-based inliner has always
been similarly unreliable, well maybe it isn't a regression, but also maybe
the inliner should just be disabled on the release branches ?


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

Re: A gcc-cris bug?

[Andrew Pinski]

On Oct 6, 2004, at 10:47 AM, Dave Korn wrote:

>   Maybe, but it does make -O3 unusable, doesn't it?  I know it's meant 
> to be
> 'unsafe' and come with suitable health warnings, but this sort of bad
> codegen just seems beyond coping with.  If the tree-based inliner has 
> always
> been similarly unreliable, well maybe it isn't a regression, but also 
> maybe
> the inliner should just be disabled on the release branches ?

But for 2.95.x there was no tree based inliner so it has nothing to do
with the inliner at all but rather a loop optimization or something 
else.

-- Pinski

Re: A gcc-cris bug?

[Andrew Pinski]

On Oct 6, 2004, at 10:47 AM, Dave Korn wrote:
>
>   Maybe, but it does make -O3 unusable, doesn't it?  I know it's meant 
> to be
> 'unsafe' and come with suitable health warnings, but this sort of bad
> codegen just seems beyond coping with.  If the tree-based inliner has 
> always
> been similarly unreliable, well maybe it isn't a regression, but also 
> maybe
> the inliner should just be disabled on the release branches ?

Another example which has the same bug in 3.4 and before:
void main ()
{
   int i;

   for (i = 0; i < foo; i++)
     {
       foo = 0;
     }
   printf("foo is: %d, i is: %d\n",foo,i);
}

so I just provided it has nothing to do with the inliner at all.


-- Pinski

RE: A gcc-cris bug?

[Dave Korn]

> -----Original Message-----
> From: Andrew Pinski 
> Sent: 06 October 2004 15:57

> Another example which has the same bug in 3.4 and before:
> void main ()
> {
>    int i;
> 
>    for (i = 0; i < foo; i++)
>      {
>        foo = 0;
>      }
>    printf("foo is: %d, i is: %d\n",foo,i);
> }
> 
> so I just provided it has nothing to do with the inliner at all.
> 

  Yep, and it even works (or rather, doesn't work) if you make foo a local
variable.  And it goes wrong at -O2 as well as -O3.  But -fno-loop-optimize
stops it.

  I guess it just goes to show that a dynamically-varying loop bound is a
pretty rare programming idiom, or people would have run up against this more
often before.......

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

RE: A gcc-cris bug?

[Graham Stott]

All,

This goes all the way back to at least 2.95.2

One problem is the insn "foo = 0" gets moved after the loop end because
loop optimize determines that it's loop invariant but isn't checking 
if the insn would modify the loop termination condition.

Graham

RE: A gcc-cris bug?

[Dave Korn]

> -----Original Message-----
> From: Graham Stott 
> Sent: 06 October 2004 17:34
> To: Dave Korn; 'Andrew Pinski'
> Cc: 'Richard Guenther'; gcc@gcc.gnu.org; 'Diego Novillo'; 'Tal Agmon'
> Subject: RE: A gcc-cris bug?
> 
> All,
> 
> This goes all the way back to at least 2.95.2
> 
> One problem is the insn "foo = 0" gets moved after the loop 
> end because
> loop optimize determines that it's loop invariant but isn't checking 
> if the insn would modify the loop termination condition.

  I'm sure you're along the right lines here, but notice that in the
original source code I posted, the "foo=0" assignment wasn't moved out of
the loop: it was right there in the middle:

	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)

  I also tried compiling the testcase with "-O2 -fno-move-all-movables", but
that didn't fix it.

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

RE: A gcc-cris bug?

[Graham Stott]

All,

> > One problem is the insn "foo = 0" gets moved after the loop 
> > end because
> > loop optimize determines that it's loop invariant but isn't checking 
> > if the insn would modify the loop termination condition.
Actually this isn't a problem because the loop optimizer does notice
that the loop termination condition has been modified.

int main()
{
  int foo = 100;
  int i;

  for (i = A; i < foo; i++)
    foo = B;
}

When B > A the loop iterates the correct # of times which is B - A + 1,
infact the whole loop gets optimized away :-). But when B <= A we end up
with a decrement-until-zero loop starting at B-A which for some reason
doesn't get optimized away.
 
> 
>   I'm sure you're along the right lines here, but notice that in the
> original source code I posted, the "foo=0" assignment wasn't moved out of
> the loop: it was right there in the middle:

I don't have your testcase anymore
> 

Graham

Re: A gcc-cris bug?

[Paolo Bonzini]

Graham Stott wrote:
> All,
> 
> 
>>>One problem is the insn "foo = 0" gets moved after the loop 
>>>end because
>>>loop optimize determines that it's loop invariant but isn't checking 
>>>if the insn would modify the loop termination condition.
> 
> Actually this isn't a problem because the loop optimizer does notice
> that the loop termination condition has been modified.
> 
> int main()
> {
>   int foo = 100;
>   int i;
> 
>   for (i = A; i < foo; i++)
>     foo = B;
> }
> 
> When B > A the loop iterates the correct # of times which is B - A + 1,
> infact the whole loop gets optimized away :-). But when B <= A we end up
> with a decrement-until-zero loop starting at B-A which for some reason
> doesn't get optimized away.

Optimizing away the loop may only paper over the problem.  What happens 
if you add a "if (i != B + 1) abort ();", in the various cases?

I'm sending a patch shortly.

Paolo

Re: A gcc-cris bug?

[Richard Guenther]

On Wed, 6 Oct 2004 16:32:58 +0100, Dave Korn <dk@artimi.com> wrote:
> > -----Original Message-----
> > From: Andrew Pinski
> > Sent: 06 October 2004 15:57
> 
> > Another example which has the same bug in 3.4 and before:
> > void main ()
> > {
> >    int i;
> >
> >    for (i = 0; i < foo; i++)
> >      {
> >        foo = 0;
> >      }
> >    printf("foo is: %d, i is: %d\n",foo,i);
> > }
> >
> > so I just provided it has nothing to do with the inliner at all.
> >
> 
>   Yep, and it even works (or rather, doesn't work) if you make foo a local
> variable.  And it goes wrong at -O2 as well as -O3.  But -fno-loop-optimize
> stops it.

Using unsigned int for i fixes the problem as well.

Richard.

Re: A gcc-cris bug?

[Paolo Bonzini]

Graham Stott wrote:
> All,
> 
> 
>>>One problem is the insn "foo = 0" gets moved after the loop 
>>>end because
>>>loop optimize determines that it's loop invariant but isn't checking 
>>>if the insn would modify the loop termination condition.
> 
> Actually this isn't a problem because the loop optimizer does notice
> that the loop termination condition has been modified.
> 
> int main()
> {
>   int foo = 100;
>   int i;
> 
>   for (i = A; i < foo; i++)
>     foo = B;
> }
> 
> When B > A the loop iterates the correct # of times which is B - A + 1,
> infact the whole loop gets optimized away :-). But when B <= A we end up
> with a decrement-until-zero loop starting at B-A which for some reason
> doesn't get optimized away.

Optimizing away the loop may only paper over the problem.  What happens 
if you add a "if (i != B + 1) abort ();", in the various cases?

I'm sending a patch shortly.

Paolo

Re: A gcc-cris bug?

[Hans-Peter Nilsson]

On Wed, 6 Oct 2004, Tal Agmon wrote:
> Hi,
>
> Can someone please check the following test on gcc-3.4.2, target=cris,
> using -O3?

Although the original question is mostly moot (it's not a bug
specific to the CRIS port; it repeats on most targets), but it
deserves a reply.  I checked not exactly gcc-3.4.2, but the 3.4
branch as of "Sat Oct 9 18:30:21 GMT 2004" (plus up to an hour,
I guess; I rsync:ed and there were problems which I fixed
locally).

> I believe it will expose a gcc bug.
> Currently it produces a bug on the crx architecture which is not an
> official part
> of gcc, I don't have the full cris toolchain but I created the compiler
> and I see
> a similar problem gets reproduced.

I feel honored that the CRIS port is used for port benchmarking! :-)

The problem is indeed reproduced; at least in this variant of
the test, necessary to fit the test-suite framework (for the
record):

-------------------------------------
int foo=100;

int f ()
{
  foo = 0;
}

extern void x (int, int) __attribute__ ((__noinline__));
extern void x (int foo, int i)
{
  if (foo != 0 || i != 1)
    abort ();
  exit (0);
}

int main ()
{
  int i;

  for (i = 0; i < foo; i++)
  {
      f ();
  }

  x (foo, i);
  return 1;
}
-------------------------------------

The test also fails on most other cross targets with available
simulators: v850-unknown-elf/v850-sim,
h8300-hitachi-hms/h8300-sim, m32r-unknown-elf/m32r-sim,
mn10300-unknown-elf/mn10300-sim, frv-unknown-elf/frv-sim,
arm-unknown-elf/arm-sim, mips-unknown-elf/mips-sim,
powerpc-unknown-eabisim/powerpc-sim, sh-hms-sim/sh-hms-sim.

Strangely enough, it doesn't fail for mmix-knuth-mmixware.
Maybe I should check into why...

brgds, H-P