#3355 comparison AST bug (on mcs51)

[Philipp Klaus Krause]

Edit: This started out as a feature request for _BitInt for mcs51, but it now turned out that the issue that was blocking _BitInt support for mcs51 is a bug that can be reproduced when using a plain unsigned char instead of _BitInt.

Original ticket test below:

As of [13207], most of the work for \BitInt for mcs51 has been done in the _BitInt branch (it probably will be merged to trunk soon).
However, there are still a few remaining regression tests failures when enabling _BitInt by changing the maximum size for _BitInt from 0 to 64 in src/mcs51/main.c.

The issues should be fixed, and _BitInt support enabled.

[Philipp Klaus Krause]

I simplified the regression failure down to this:

typedef unsigned _BitInt(8) ubitinttype;

volatile ubitinttype ua, ub;

int f(void)
{
    if((ua <= ub) == 1) // No bug without the == 1 here.
        return 1;
    return 0;
}

When targeting mcs51, SDCC thinks that the if condition is always false. Oddly, the AST is already wrong (I didn't expect the choice of the port to affect the AST here).

Philipp

[Philipp Klaus Krause]

The problem is there even without using bit-precise types:

volatile unsigned char ua, ub;

int f(void)
{
    if((ua <= ub) == 1)
        return 1;
    return 0;
}

I added a (currently disabled) test in [r13220] when enabled, it fails for both mcs51 and ds390, but not other ports. However, for all ports I see "tree ([…]) not decorated" output on --dump-ast.

[Philipp Klaus Krause]

Ticket moved from /p/sdcc/feature-requests/789/

Can't be converted:

• _milestone:

[Philipp Klaus Krause]

Looks like for mcs51, checkConstantRange thinks that the left side of the == has a possible value range from -1 to 0, and thus can never be 1. I don't know yet why that happens, nor why it happens for mcs51, but not stm8.

[Philipp Klaus Krause]

Fixed in [r15572]. This was a bug in the handling of the (mcs51/ds390-specific) data type __bit, which was introduced by an optimization.