Rich Testardi

CW7 for CF switch/case optimized code generation bug?

Discussion created by Rich Testardi on Mar 23, 2008
Latest reply on May 28, 2008 by Rich Testardi
Hi,
 
I am seeing what appears to be a code generation bug when I turn up optimization (from level 1 to level 2) on a switch/case statement.  The compiler is generating a jump table in the code segment, and the destination of the jump table skips (at least) one instruction critical to the case statement.
 
The switch statement looks like:
 
    switch (code) {
00007580: 122EFF65        move.b   -155(a6),d1
00007584: 7000            moveq    #0,d0
00007586: 1001            move.b   d1,d0
00007588: 0C800000009C    cmpi.l   #156,d0
0000758E: 6E000B5E        bgt.w    run_bytecode+0xc12 (0x80ee); 0x000080ee
00007592: 0C8000000080    cmpi.l   #128,d0
00007598: 6D000B54        blt.w    run_bytecode+0xc12 (0x80ee); 0x000080ee
0000759C: 048000000080    subi.l   #128,d0
000075A2: 303B0A08        move.w   (8,pc,d0.l*2),d0
000075A6: 48C0            ext.l    d0
000075A8: 4EFB0A00        jmp      (pc,d0.l*2)
 
The jump table that follows is:
 
000075AC:
  05A3  001E  0023  05A2 
  05A2  006F  05A2  05A2 
  05A2  05A2  05A2  01B6 
  0228  05A2  05A2    02CA 
  034E  03CE  0401  042E 
  04B3  05A2  05A2  050D 
  0541  0567  0567  04F3 
  0500  2D6E
 
I am taking the entry at offset 5 ("code" is 0x85 and the case density space begins at 0x80) -- which is 006f, leading to a branch destination of 0x7688.
 
The problem is that 0x7688 is what appears to be three instructions into my case (which should begin at 0x767C):
 
        case code_dim:
0000767C: 282E0010        move.l   16(a6),d4
00007680: 7A01            moveq    #1,d5
                    var_type = code_ram;
00007682: 263C00000087    move.l   #135,d3
00007688: 2007            move.l   d7,d0
0000768A: D086            add.l    d6,d0
...
 
I understand that with optimized code, the disassembly and source don't always align exactly; however, the "move.l   #135,d3" is never executed, and that is passed as an argument into an underlying function that asserts it is passed correctly, so it is a required part of the case.
 
Can anyone suggest what I can do to work around this, or should I just not use the optimizer?
 
I have verified that at level 1 optimization the jump table (which is still used) is correct.
 
Thanks.
 
-- Rich
 

Outcomes