rmariani@watmum.UUCP (Rico Mariani) (12/06/86)
Could someone check to see if this code compiles OK under V3.30 or higher
of Aztec? It gives the same kind of bug as the last bit of code, error
at assembly time
main()
{
int box[1], i;
(box+i)[0] =
(box+i)[0] =
(box+i)[0] =
(box+i*i)[0] = 0;
}
It's very subtle, as any tweaking of the above results in a correct
compilation, e.g. if you delete one of the redundant assignments it's
just fine...
This is so similar to the other bug that it just might have been corrected
along with it, but just in case (and as a further confidence test...)
On the whole, I've thrown a big mess of the ugliest C source you could
imagine at Aztec and it has compiled most of it without problems. I'm
very impressed...
-Rico
Here's the assembler that the above code generates.
;:ts=8
;main()
;{
public _main
_main:
link a5,#.2
movem.l .3,-(sp)
; int box[1], i;
;
; (box+i)[0] =
; (box+i)[0] =
; (box+i)[0] =
; (box+i*i)[0] = 0;
move.l -8(a5),d3
asl.l #2,d3
lea -4(a5),a6
move.l -8(a5),d2
asl.l #2,d2 <--- this value is already in d3
lea -4(a5),a1 <--- this one is in a6...
move.l -8(a5),d1
asl.l #2,d1 <--- and again
lea -4(a5),a0 <--- with both values...
move.l -8(a5),d0
move.l d1,-(sp)
move.l -8(a5),d1
jsr .mulu# <--- perfectly reasonable mulu call this time
asl.l #2,d0
move.l a6,-(sp) <--- compiler doesn't know that it doesn't
lea -4(a5),a6 have to save this...
clr.l (a6,d0.l)
clr.l (a0,.l) <---- look familiar ??
clr.l (a1,d2.l)
move.l (sp)+,a6
move.l (sp)+,d1
clr.l (a6,d3.l)
;}
.4
movem.l (sp)+,.3
unlk a5
rts
.2 equ -8
.3 reg
public .begin
dseg
cseg
end