Re: Bug in code generation of gcc-2.95.2

[Franz Sirl <Franz dot Sirl-kernel at lauterbach dot com>]

Am Tue, 04 Jan 2000 schrieb Andi Kleen:
>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.

Well, on Linux/PPC gcc-2.95.2 compiles this just fine:

func:
        lis 9,Picklist@ha
        la 9,Picklist@l(9)
        li 11,0		// index
.L5:
        lwz 0,4(9)
        addi 11,11,1
        cmpwi 0,11,6
        stw 0,0(9)
        addi 9,9,4
        bc 4,1,.L5	// branch if less or equal
        li 3,0
        blr

The main difference seems to be that on PPC 'index' starts at 0 and is not used
in the pointer calculation. It seems the miscompile happens because the scaling
capability of the x86 instruction set is misoptimized?

Franz.