#1166 regression test onebyte.c fails on ppc64 host

closed-fixed
5
2013-05-25
2006-07-08
No

Processing onebyte.c
gen/ucz80/onebyte/onebyte_attrL_none_attrR_none.out:15:---
FAIL: "Assertion failed" on ~ (char) 0x80 == (short)
0x007f at
gen/ucz80/onebyte/onebyte_attrL_none_attrR_none.c:188
gen/ucz80/onebyte/onebyte_attrL_none_attrR_none.out:16:---
FAIL: "Assertion failed" on ~ (char) 0x80 > 0 at
gen/ucz80/onebyte/onebyte_attrL_none_attrR_none.c:188
gen/ucz80/onebyte/onebyte_attrL_none_attrR_volatile.out:15:---
FAIL: "Assertion failed" on ~ (char) 0x80 == (short)
0x007f at
gen/ucz80/onebyte/onebyte_attrL_none_attrR_volatile.c:188
gen/ucz80/onebyte/onebyte_attrL_none_attrR_volatile.out:16:---
FAIL: "Assertion failed" on ~ (char) 0x80 > 0 at
gen/ucz80/onebyte/onebyte_attrL_none_attrR_volatile.c:188
gen/ucz80/onebyte/onebyte_attrL_volatile_attrR_none.out:15:---
FAIL: "Assertion failed" on ~ (char) 0x80 == (short)
0x007f at
gen/ucz80/onebyte/onebyte_attrL_volatile_attrR_none.c:188
gen/ucz80/onebyte/onebyte_attrL_volatile_attrR_none.out:16:---
FAIL: "Assertion failed" on ~ (char) 0x80 > 0 at
gen/ucz80/onebyte/onebyte_attrL_volatile_attrR_none.c:188
gen/ucz80/onebyte/onebyte_attrL_volatile_attrR_volatile.out:15:---
FAIL: "Assertion failed" on ~ (char) 0x80 == (short)
0x007f at
gen/ucz80/onebyte/onebyte_attrL_volatile_attrR_volatile.c:188
gen/ucz80/onebyte/onebyte_attrL_volatile_attrR_volatile.out:16:---
FAIL: "Assertion failed" on ~ (char) 0x80 > 0 at
gen/ucz80/onebyte/onebyte_attrL_volatile_attrR_volatile.c:188

$ ./sdcc --version
SDCC :
mcs51/gbz80/z80/avr/ds390/pic16/pic14/TININative/xa51/ds400/hc08
2.5.6 #4273 (Jul 7 2006) (UNIX)

The test fails on all tergets, so it seems that it is a
front-end problem.

Borut

Discussion

  • Borut Ražem

    Borut Ražem - 2006-07-08

    Logged In: YES
    user_id=568035

    The ppc64 regression tests are executed on CF
    openpower-linux1 machine.

    Borut

     
  • Maarten Brock

    Maarten Brock - 2006-07-24

    Logged In: YES
    user_id=888171

    In sdccconf.h it says:

    #define TYPE_BYTE char
    #define TYPE_WORD short
    #define TYPE_DWORD int
    #define TYPE_UBYTE unsigned TYPE_BYTE
    #define TYPE_UWORD unsigned TYPE_WORD
    #define TYPE_UDWORD unsigned TYPE_DWORD

    #define WORDS_BIGENDIAN 1

    However, char is unsigned by default on this machine! As
    this little test program shows:

    #include <stdio.h>

    int main(void)
    {
    char x = -1;
    int y = x;
    printf("y = %d\n", y);
    return 0;
    }

    y = 255

    I'm not sure how to solve this. This is the work of the
    configure script and I'm not really familiar with that.

    I think it needs a two step solution:
    1) Rename $TYPE_BYTE to something like $TYPE_CHAR
    2) Define TYPE_BYTE as signed $TYPE_CHAR and TYPE_UBYTE as
    unsigned $TYPE_CHAR

    Borut, can you help?

     
  • Borut Ražem

    Borut Ražem - 2006-07-24

    Logged In: YES
    user_id=568035

    The proper solution is to use the AC_C_CHAR_UNSIGNED in
    configure.in:

    ...

    AC_C_CHAR_UNSIGNED

    type_name()
    {
    if expr "$ac_cv_sizeof_char" '>=' "$1" >/dev/null; then
    if test "$ac_cv_c_char_unsigned" = "yes"; then
    echo "signed char"
    else
    echo "char"
    fi
    exit
    fi
    if expr "$ac_cv_sizeof_short" '>=' "$1" >/dev/null; then
    echo "short"
    exit
    fi
    if expr "$ac_cv_sizeof_int" '>=' "$1" >/dev/null; then
    echo "int"
    exit
    fi
    if expr "$ac_cv_sizeof_long" '>=' "$1" >/dev/null; then
    echo "long"
    exit
    fi
    echo "long"
    }
    ...

    I'll fix it.

    Borut

     
  • Maarten Brock

    Maarten Brock - 2006-07-24

    Logged In: YES
    user_id=888171

    That is probably not enough, because it will define
    TYPE_UBYTE as unsigned signed char

     
  • Maarten Brock

    Maarten Brock - 2006-07-26
    • labels: 101552 --> Build system
    • milestone: --> fixed
    • assigned_to: nobody --> borutr
    • status: open --> closed-fixed
     
  • Maarten Brock

    Maarten Brock - 2006-07-26

    Logged In: YES
    user_id=888171

    Borut, You fixed it. SDCC #4300.

     

Log in to post a comment.