Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!njin!princeton!notecnirp!nfs From: nfs@notecnirp.Princeton.EDU (Norbert Schlenker) Newsgroups: comp.os.minix Subject: Another bug in cc(1) under PC Minix 1.3 Keywords: PC Minix 1.3 cc bug Message-ID: <18674@princeton.Princeton.EDU> Date: 16 Aug 89 20:49:52 GMT Sender: news@princeton.Princeton.EDU Reply-To: nfs@princeton.Princeton.EDU (Norbert Schlenker) Organization: Dept. of Computer Science, Princeton University Lines: 55 Here's another cc(1) bug under PC Minix 1.3. I ran across this while trying to develop an ANSI standard stdarg.h header file. Consider the source: void func(x) int x; { char *ap; char y, z; ap = ((char *) &x) + sizeof(x); y = ((char *) (ap += sizeof(char)))[-1]; z = ((char *) (ap += sizeof(char)))[-1]; } The compiler produces: ... (normal header deleted) lea ax,6(bp) mov si,ax <-- apparently ap mov bx,si inc si movb al,(bx) movb -3(bp),al <-- apparently y inc si movb al,(bx) movb -4(bp),al <-- apparently z jmp .sret But note that z is pulled out of the same location as y, which isn't right. With y and z as int's, the compiler produces good code; e.g. ... (normal header deleted) lea ax,6(bp) mov si,ax add si,#2 mov ax,-2(si) mov -4(bp),ax add si,#2 mov ax,-2(si) mov -6(bp),ax jmp .sret I would argue that this is not only good code, but better than in the previous case. Is there some constitutional prohibition against using si as a character pointer? One further note: While fiddling with this, I thought perhaps removing the optimization phase in the compile might fix things up. Under 1.3, though, cc always calls /usr/lib/opt no matter what arguments you give it. So I tried doing the whole thing by hand, first cpp, then cem, skipping opt, and then cg. But cg barfed on the .k file. What does opt do when transforming *.k to *.m? Can opt be fed a command line argument that will inhibit optimization? Norbert