Re: Bug in code generation of gcc-2.95.2

[Andi Kleen <ak at muc dot de>]

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

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