#3205 crash on 2048 subsequent assignments of 0 to pointer

[Philipp Klaus Krause]

SDCC crashes when compiling the regression test gcc-torture-execute-p18298 for gbz80 on FreeBSD on 64-Bit ARM (as I found on my Raspi 4):

philipp@generic:~/sdcc/support/regression $ ../../bin/sdcc --fverbose-asm -DNO_VARARGS --nostdinc -I../.. -mgbz80 --less-pedantic --profile -I./fwk/include -I./tests -I../../device/include -c gen/ucgbz80/gcc-torture-execute-p18298/gcc-torture-execute-p18298.c -o gen/ucgbz80/gcc-torture-execute-p18298/gcc-torture-execute-p18298.rel
Illegal instruction (core dumped)

[Philipp Klaus Krause]

This does happen deep (approx. 7000) in a recursion in tree_dec_ralloc_nodes in the register allocator. But is doesn't look like a stack overflow: The depth of the recursion is the same both for a stacksize limit of 1 GB as for one of 512 MB (both set by ulimit -s).

[Philipp Klaus Krause]

Since [r12197], this can no longer be reproduced, since gbz80 no generates different code for that test. However, the underlying issue is probably still there. Maybe I can come up with a test case specifically for this bug (I guess a __naked function containing 2048 writes to a global volatile char *, but nothing else, should do).

[Philipp Klaus Krause]

In [r12203] I created a regression test that even after the changes in [r12197] reproduces the bug on FreeBSD 13 on aarch64 for gbz80. Furthermore, it can even reproduce the bug on Debian GNU/Linux on amd64 when compiling for pdk15.

[Philipp Klaus Krause]

This is hard to debug. I tried current svn on Debian GN/Linux testing. I see the error only for the mos6501 port. An only if mos6502/ralloc2.cc is compiled using -O2. Without -O2, even valgrind sees no error.