#2274 SDCC crashes with segfault on variable initalization

[Sam]

The attached code causes SDCC to crash with a segmentation fault. The issue seems to be the initalization of a variable with another variable of the same name from an outer block.

It seems to depend on a few factors, for example the type of the two variables must be different and there has to be some function involved in the initalization.

This bug doesn't seem very important to me* as it happens with code you never should write in the first place...

Versions tested:

• SDCC : mcs51/gbz80/z80/z180/r2k/r3ka/ds390/pic16/pic14/TININative/ds400/hc08/s08 3.2.0 #8008 (Sep 2 2013) (Linux)
• SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/pic16/pic14/TININative/ds400/hc08/s08/stm8 3.4.1 #9021 (May 8 2014) (Linux)

Compile with:
sdcc-sdcc segv.c

Result:
/usr/bin/sdcc-sdcc: Zeile 3: 23526 Speicherzugriffsfehler (Speicherabzug geschrieben) /usr/libexec/sdcc/sdcc "$@"

Cheers,
Sam

---

* Apart from it being my first compiler bug. Yay!

[Sam]

I simplified it a bit further. Also, gcc accepts it ;)

[Ben Shi]

It seems that the second segv.c makes several functions of the front end of SDCC into infinite indirect recursive calling, and finally get to stack overflow.

I am not familiar with the front end.

[Ben Shi]

Fixed in reversion #9168.

Now SDCC no longer crashes, and only prints the (expected) warning messages.

warning 84: 'auto' variable 'a' may be used before initialization

[Maarten Brock]

May I conclude from this that the double name with different scope had nothing to do with it? And if we would reintroduce this in the regression test the warning 84 would disappear?

[Maarten Brock]

It seems not so. If I change bug-2274.c to this:

void testUndef (void) __reentrant
{
  int a = 1;
  char b = 2;
  int c = 3;
  char d = 4;
  {
    /* SDCC should not crash, but only prints warning messages. */
    char a = func_0 (a);
    char b = func_1 (b);
    int c = func_2 (c);
    int d = func_3 (d);
  }
}

I still see the warnings from SDCC where the host (gcc) test is silent. However it seems sdcc is right: a is used uninitialized as func_0 (a) does not reference the outer int a. Enabling all gcc warnings with -Wall makes gcc also warn about it.

So the test is ok, but if you expect the warning please disable it with a pragma.