Bug in code generation of gcc-2.95.2
Franz Sirl
Franz.Sirl-kernel@lauterbach.com
Tue Jan 4 13:51:00 GMT 2000
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.
More information about the Gcc-bugs
mailing list