Re: Bug in code generation of gcc-2.95.2

[Andi Kleen <ak at muc dot de>]

On Tue, Jan 04, 2000 at 04:24:19PM +0100, Franz Sirl wrote:
> Am Sun, 02 Jan 2000 schrieb Andi Kleen:
> >jacob@jacob.remcomp.fr writes:
> >
> >> Consider the following code:
> >> 
> >> char *Picklist[8];
> >> int func()
> >> {
> >> 	int i;
> >> 
> >> 	i = 0;
> >> 	while (i < 7) {
> >> 		Picklist[i] = Picklist[i+1];
> >> 		i++;
> >> 	}
> >> 	return 0;
> >> }
> >> The code generated for this loop by gcc is:
> >> 	movl	$04b0940,%ecx	(puts PickList in ecx)
> >> 	movl	$0x1,%edx	(index, starts at one)
> >> loop:
> >> 	movl	(%ecx,%edx,4),%eax  (puts Picklist[i+1] in eax)
> >> 	movl	%eax,-4(%ecx,%edx)  (puts eax into Picklist[i])
> >> 	leal	0x1(%edx),%edi      (increments edx into edi)
> >> 	movl	%edi,%edx           (copies into edx the incremented value)
> >> 	cmpl	$0x6,%edx           (HERE IS THE BUG!!!!!!!!!)
> >> 	jle	loop
> >> 
> >> Gcc is optimizing the access to the table, using a loop counter starting at
> >> 1 instead of zero. This could be quite ok, but gcc forgets to increment the
> >>                                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> integer at the end of the test!!! This loop is copying
> >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >> 	Picklist[5] = Picklist[6]
> >> as the LAST copy, instead of the correct
> >> 	Picklist[6] = Picklist[7]
> >> as SPECIFIED IN THE C Code!!!
> >> 
> >> If you pre-increment the loop index, then you should increment the boundary
> >> test too, if not, as this is the case with the shown C code, the generated code
> >> fails to copy the last element of the array.
> >[...]
> >
> >egcs 1.1 compiles it correctly.
> >2.95.1 fails.
> >gcc-current seems to compile it correctly, but only because the loop is 
> >turned into a down counting loop (it is not clear if the bug wouldn't resurface
> >in loops that cannot be converted to down counting for some reason) 
> >It seems like a serious bug.
> 
> Andi, would you mind trying it with the gcc-2_95-branch from CVS? I cannot
> reproduce it on powerpc-linux-gnu here with current gcc-2.95.3pre.

I just tried it with a freshly refetched gcc-2_95-branch, and it has 
the same problem. The culprit seems to be clearly the loop pass, 
in the gcse rtl dump everything is still ok, after loop ran the comparison
is wrong.

-Andi

-- 
This is like TV. I don't like TV.