Bug in code generation of gcc-2.95.2

[Franz Sirl]

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.

Franz.