This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Call to labs() sometimes generates incorrect assembly for an 8-bit signed integer

Hi,

I found a problem in the generated code for the following scenario: when calling the labs() function for an 8-bit signed integer and the result is stored in an unsigened 8-bit integer, the sign extension step is missing from the generated assembly code, which in fact calls the abs() function. This issue is causing a larger application to produce incorrect results.

In order to reproduce it, compile this simplified example code and look at the assembly code for the function call:

#include <stdlib.h>

struct _fxp_heap {
    signed char iVal;
    unsigned char iAbs, iAbsExpected;
} fxp_heap;

struct _fxp_heap *pfxp_heap = &fxp_heap;

int main()
{
   
    pfxp_heap->iVal = (signed char)-10;
    pfxp_heap->iAbsExpected = (unsigned char)10;
    pfxp_heap->iAbs = labs(pfxp_heap->iVal);
    if (pfxp_heap->iAbs != pfxp_heap->iAbsExpected)
        return 1;
    return 0;
}

I am using the latest version (3.2.3) of the CCS compiler for msp430.

If it is a compiler problem, is it possible to fix?

Thanks,

Alpar

  • I'll try to reproduce this and get back to you when I have more information.

  • In this example, the result of labs() is being stored in a unsigned char while the definition of labs/abs takes in a signed long/int argument and returns a signed long/int value. Since the result is being stored in unsigned char, it looks like the compiler is removing the sign extension. I'd have to check further if this is a bug but doing the following to cast the type to signed results in expected behavior:

    pfxp_heap->iAbs = (signed char) labs(pfxp_heap->iVal);