#3354 Wrong use of the stack

[Ragozini Arturo]

I am using
SDCC : mcs51/z80/z180/r2k/r2ka/r3ka/sm83/tlcs90/ez80_z80/z80n/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8/pdk13/pdk14/pdk15/mos6502 4.2.0 #13081 (MINGW32)
published under GNU General Public License (GPL)

The very same C code produces good or broken code according to the optimisation level
Using this command line
set CCFLAGS=-mz80 --opt-code-speed --std-c11 --no-std-crt0 --nostdlib --max-allocs-per-node 200000
The into.c code results in intro_good.asm that correctly returns to the main when
void intro(void) __banked
is executed.

reducing the optimisation with --max-allocs-per-node 20000 the resulting intro_bad.asm code is generated where the same intro(void) is messing with the stack at each call of function

void FireIteration(char *b) __sdcccall(1)

In attach
intro.c
intro_good.asm compiled with --max-allocs-per-node 200000
intro_broken.asm compiled with --max-allocs-per-node 20000

[Ragozini Arturo]

The initial C file

[Ragozini Arturo]

The compiled ROM for good and broken intro
Use any MSX2 configuration on Bluemsx or OpenMSX to run them

[Ragozini Arturo]

The bug persists even with --max-allocs-per-node 50000
In attach the broken ASM file with this parameter, where the stack counting is corrupted as well
The C file is the same above

[Ragozini Arturo]

The problems solves with --max-allocs-per-node 100000 where the ASM source becomes identical to the one obtained with with --max-allocs-per-node 200000

[Ragozini Arturo]

I've found the problem: some subroutines of mine (in ASM) were changing IX.
According to the level of optimisation, in one case the stack is restored on exit by INC/DEC SP (higher optimisation), in the other it is restored by LD SP,IX, with the wrong IX value.
So, no problems with the compiler. Sorry for the alarm

[Philipp Klaus Krause]

SDCC assumes that IX is always preserved / saved by the caller.