[comp.os.minix] Another bug in cc

nfs@notecnirp.Princeton.EDU (Norbert Schlenker) (08/17/89)

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