Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#485 Not all local variables stored over func call

closed-fixed
nobody
5
2013-05-25
2003-03-19
Jarek Zych
No

SDCC : mcs51/gbz80/z80/avr/ds390/pic14/TININative/xa51 2.3.4 (Mar 18 2003) (MINGW32)

In "testfunction" when calling "i=getchfunction()"; only register allocated by variable "n" is push-poped

;test.c:15: i=getchfunction();
; genCall
push ar2
lcall _getchfunction
mov a,dpl
pop ar2
; genAssign

My workaround is to initialize variable b0 to any value. In that case push-pop are generated to variables
"n" and "b0" and everything works fine.

===========================================
unsigned char xxxxx;
unsigned char getchfunction(void);

void testfunction(void)
{
unsigned char n=0;
unsigned char b0;
for(;;)
{
unsigned char i;
i=getchfunction(); // <<< BUG >>>
if(i & 0x80)
{
if(i&0xf0== 0x83)
{
n=1;
b0=i;
}
else
n=0;
}
else if(n==1)
{
xxxxx=i+b0; // <<< b0 value is invalid>>>
break;
}
}
}

Discussion

  • Bernhard Held
    Bernhard Held
    2003-03-19

    • labels: 101550 --> Live range problems
     
  • Bernhard Held
    Bernhard Held
    2003-03-19

    Logged In: YES
    user_id=203539

    Ok, there is a bug in SDCC. But your source is bugy too, and
    it doesn't even expose the bug:

    > if(i&0xf0== 0x83)
    will hardly do what you want, it's always false. Then b0 is
    never assigned a value, n is always 0, and at the end b0 is
    never ever used.

    Replacing the line above with:
    if ((i & 0xf0) == 0x83)
    exposes however the bug!

    Bernhard

     
  • Logged In: NO

    Well ... I tried to shorten my program as much as possible to expose the bug clearly. As a result my example
    wasn't correct! Sorry!!! Fine that You still coud see the problem.

     
  • Erik Petrich
    Erik Petrich
    2003-12-16

    • milestone: --> fixed
    • status: open --> closed-fixed
     
  • Erik Petrich
    Erik Petrich
    2003-12-16

    Logged In: YES
    user_id=635249

    I have verified that the new live range code (specifcally,
    Klaus's 2003/10/28 cvs commit) has fixed this bug.