SourceForge has been redesigned. Learn more.
Close

#2163 iCode labels bleed thru to C level

closed-fixed
None
Front-end
5
2013-12-18
2013-05-13
No

Trying to compile this program:

int foo();
int a;

int main()
{
    if (a) foo();
_iftrue_0:
    return 0;
}

with:

$ sdcc -v
SDCC : mcs51 3.3.0/*rc1*/ # (May 13 2013) (Linux)
$ sdcc -S label-clash.c

Leads to:

label-clash.c:7: error 56: Duplicate label '_iftrue_0'

That's because iCode creates label named like that, and doesn't escape C label names.

Arguably, one unlikely would hit this in practice, submitting only because of suggestion on the mailing list.

Discussion

  • Philipp Klaus Krause

    The weird aspect here is that the code compiles fine as soon as I slightly change the example. E.g. just adding a function

    void f(void)
    {
    if (a)
    a++;
    }

    before main makes the issue go away.

    Philipp

     
  • Maarten Brock

    Maarten Brock - 2013-12-18

    That is not so weird once you realize the number comes from a static counter. So now _iftrue_0 is generated in f() and _iftrue_1 in main(). But the generated _iftrue_0 is no longer alive in main() so no clash with the user specified _iftrue_0.

    A similar problem exists when using _str_0 which the compiler generates for string constants.

     
  • Philipp Klaus Krause

    I guess the easiest fix for this bug would be to make sdcc prefix the generated labels, so we would e.g. get iftrue_0 and str_0, or maybe even sdcc_iftrue_0 and sdcc_str_0.

    Philipp

     
  • Maarten Brock

    Maarten Brock - 2013-12-18
    • status: open --> closed-fixed
    • assigned_to: Maarten Brock
     
  • Maarten Brock

    Maarten Brock - 2013-12-18

    Fixed in SDCC 3.3.2 #8910

     

Log in to post a comment.