#3560 Missing code (suspected) in a generated z80 asm file

[Cgyed]

#include <stdint.h>

/* volatile data to avoid optimization of the empty functions  */ 
volatile uint8_t data;

typedef enum { haut, bas, gauche, droite, entree} touche;

/* empty function - originally supposed to move a piece and put 1 in end_piece if the piece can't move anymore */
void depl(uint16_t touche, uint8_t* end_piece)
{
    data = *end_piece + (uint8_t)touche;
}

/* empty function - originally supposed to test if the deplacement is possible*/
uint8_t possible (uint8_t * pce)
{
    return data == *pce;
}

uint8_t key;
volatile uint8_t Control_1;
volatile uint8_t next;

void mygame()
{

    uint8_t end_piece;
    uint8_t end_game=0;

    while(! end_game) 
    {
        do
        {   
            end_piece = 0; 
            key = Control_1;

            if (!(key & 0b00000010))
                depl(bas, &end_piece);
            else if (!(key & 0b00001000))
                depl(droite, &end_piece);
            else if (!(key & 0b00000100))
                depl(gauche, &end_piece);

            /*else end_piece = 0;*/


        }
        while(!end_piece);
        end_game= (!possible(&next));
    }
}

sdcc -c -mz80 game.c

SDCC : 15 4.1.0 #12072 (MINGW64)

Hello,
I suspect a bug while compiling z80 code.
I port a tetris game from PC/gcc to master system/sdcc and a bug appears that is not be related to the port itself.

In the previous code, the end_piece = 0; (at the beginning of the do/while loop) assignation is not done in the asm file and make the game "crash".

If I uncomment /*else end_piece = 0;*/ later in the code, this assignation is done (that is another way to do what I want to) and the first assignation (now redundant) at the begining of the do/while is also done in the asm file.

Not sure if it is clear, I can add information if needed.

Thanks for this great compiler !

P.S.: Edited by @spth to fix display of code above.

[Philipp Klaus Krause]

For me, using current SDCC from svn trunk, the comment for line 29 is missing, but the zeroing is actually happening, though not at the location where it would be expected:

;game.c:30: while(! end_game) 
    ld  iy, #0
    add iy, sp
    ld  0 (iy), #0x00
00112$:
    or  a, a
    jr  NZ, 00115$

Looking at the dumps from --dump-i-code, the game.dumpdeadcode looks ok, while the game.dumploop looks broken. So the bug is introduced in loop optimizations.

[Philipp Klaus Krause]

Here is a regression test that checks for this bug.

[Philipp Klaus Krause]

Fixed in [r13896].