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.

Compiler/TMS570LS1224: Larger than 32 bit value with bitfield causes data abort

Part Number: TMS570LS1224

Tool/software: TI C/C++ Compiler

I have a structure defined as shown below.  When I try to assign a value to boot_p_response_data , I get a data abort.  The code runs fine in version 5.2.6 of the arm compiler but not 18.1.1.LTS.  Seems like a compiler bug.  I tested that this happens with values great than 32 bits.  Please advise.

struct boot_p_response

{
uint32_t id;
uint8_t dlc;
uint32_t timestamp;
bool MIA;
union
{
struct
{
// Generic bootp response data
uint64_t boot_p_response_data : 64U; //lint !e46 invalid in C99
} signals;
uint64_t data64;
uint8_t bytes[8]; 
} data __attribute__((__packed__));
};

  • Jana Fernando60 said:
    When I try to assign a value to boot_p_response_data , I get a data abort.

    For the source file which contains this assignment, please submit a test case as described in the article How to Submit a Compiler Test Case.  If there is more than one assignment in the file, please add a comment which indicates the assignment with the problem.

    Thanks and regards,

    -George

  • Please submit the requested test case.

    Thanks and regards,

    -George

  • Since it has been a while, I presume you have resolved the problem.  I'd appreciate hearing how you resolved it.

    Thanks and regards,

    -George

  • We sort of resolved it.  We are currently still using the old version of the compiler for the time being until we can put a workaround that does not require larger than 32 bit bitfields.  We found in the compiler manual the following:  

    "Bit fields are the only objects that are packed within a byte. That is, two bit fields can be stored in the
    same byte. Bit fields can range in size from 1 to 32 bits, but they never span a 4-byte boundary."

    So based on this we are planning to avoid the issue through a change in our code.

    Thanks,

    Jana