#1518 problem with bit variable

closed-fixed
5
2013-05-25
2009-03-28
No

I use the followin g routine as a BCD to ASCII converter:

/*-----------------------------------------------------------------*/
xdata unsigned char * BCD_2_ASCII(xdata unsigned char *input,
unsigned char number_of_chars, xdata unsigned char *output)
{

data unsigned char i, j, ascii;
bit leading_zero;

leading_zero=1;
j=0;
for (i=number_of_chars; i>0; i--)
{
ascii=(*(input+i-1)>>4)+'0';
leading_zero&=(ascii=='0');
if (!leading_zero)
{
*(output+j)=ascii;
j++;
}
ascii=(*(input+i-1)&0x0f)+'0';
leading_zero&=(ascii=='0');
if (!leading_zero)
{
*(output+j)=ascii;
j++;
}

}
if (leading_zero)
{
*output='0';
j++;
}

*(output+j)=0x0d;
return input+number_of_chars;

}

/*-----------------------------------------------------------------*/

I use SDCC version 2.9.0:

SDCC : mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08 2.9.0 #5416 (Mar 22 2009) (MINGW32)

I've got the following error report: Caught error 11: SIGSEGV
sdcpp.exe: fatal error: when writing output to : m

If I declare leading zero as a char, everything is OK.

If I use SDCC version 2.7.0 or 2.6.0 , I don't get error message.

Discussion

  • Robert Larice

    Robert Larice - 2009-03-28

    for debugging purpose, the offending code can be reduced to

    void foo() {
    bit bv = 1;
    char i;

    for (i=2; i>0; i--)
    bv &= (i == 1);
    }

    and compiled with
    sdcc -mmcs51 -c this.c

     
  • Robert Larice

    Robert Larice - 2009-03-28

    the problem boils down to
    mcs51/gen.c aprox line 6739, function genAnd
    with IS_OP_ACCUSE(left) == false
    but IS_OP_ACCUSE(right) == true
    the second one being most unexpected here.
    at the beginning of the function, there are several swaps
    of left and right operand ...

     
  • Robert Larice

    Robert Larice - 2009-03-30

    I propose the following regression test for this problem.
    I've also included a small change for mcs51/gen.c
    which demonstrates a cure to the issue. But I've
    to admit, I don't grasp enough of semantics and
    interaction of the IS_OP_ACCUSE AOP_CRY etc macros,
    and can't recommend to apply this just as it is.

    Index: src/mcs51/gen.c

    --- src/mcs51/gen.c (revision 5420)
    +++ src/mcs51/gen.c (working copy)
    @@ -6734,6 +6734,11 @@
    {
    emitcode ("anl", "c,%s", AOP (right)->aopu.aop_dir);
    }
    + else if (IS_OP_ACCUSE (right))
    + {
    + emitcode ("rrc", "a");
    + emitcode ("anl", "c,%s", AOP (left)->aopu.aop_dir);
    + }
    else
    {
    emitcode ("mov", "c,%s", AOP (right)->aopu.aop_dir);
    Index: support/regression/tests/my-2719592.c
    ===================================================================
    --- support/regression/tests/my-2719592.c (revision 0)
    +++ support/regression/tests/my-2719592.c (revision 0)
    @@ -0,0 +1,27 @@
    +/*
    + * my-2719592.c
    + * (compile "make -C .. ALL_TESTS='./tests/my-2719592.c'")
    + */
    +
    +#include <testfwk.h>
    +#include <stdint.h>
    +
    +#if !defined(SDCC_ds390) && !defined(SDCC_mcs51)
    +#define bit char
    +#endif
    +
    +bit foo(char i, bit bv)
    +{
    + bv &= (i == 1);
    + return bv;
    +}
    +
    +void
    +testBug(void)
    +{
    + ASSERT( !foo(0,0) );
    + ASSERT( !foo(0,1) );
    + ASSERT( !foo(1,0) );
    + ASSERT( foo(1,1) );
    +}
    +

     
  • Maarten Brock

    Maarten Brock - 2009-09-06

    Applied the patch in SDCC 2.9.2 #5512.
    Thank you.

     
  • Maarten Brock

    Maarten Brock - 2009-09-06
    • milestone: --> fixed
    • assigned_to: nobody --> maartenbrock
    • status: open --> closed-fixed
     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks