Compiler/MSP432P401R: Indirect assignment of non-aligned uint64 causes runtime fault

I have yet to find any authoritative documentation on this point.  But I'm pretty sure this statement ...

Julian Kolodko said:

d_u64_ptr = &(m_st.b_u64); // b_u64 is not 32bit aligned.

... causes a violation of the strict aliasing rule.  This rule is very detailed, but the bottom line is a type used to perform a memory access must be a close match to the type used to define the original variable.  In this statement, you copy the address of a packed member of structure to a general non-packed pointer.  Any later use of the pointer violates the rule.

Thanks and regards,

-George

G'Day George,

I accept that what I'm doing is naughty at best.  (And I'm guessing this problem is deeper than I understand - both the TI compiler and GCC have the same problem).

But, superficially at least, if a compiler can detect the 8 bit non-aligned indirect access and generate working code couldn't the compiler at least generate a warning in the case of the non-aligned indirect 64 bit access??

Indeed, as the example below shows, 8bit, 16bit and 32bit access ALL work and do exactly what you expect despite indirect access through non-aligned pointers.  Why not 64bit?

typedef struct
{
  uint8_t  d1_u8;  // mess up alignment
  uint64_t t_u64;
  uint8_t  t_u8;
  uint8_t  d2_u8;  // mess up alignment
  uint16_t t_u16;
  uint32_t t_u32;
} __attribute__ ((packed)) myStruct;

    myStruct m_st;

    uint8_t data_u8;
    uint8_t *t_u8_ptr;

    uint16_t data_u16;
    uint16_t *t_u16_ptr;

    uint32_t data_u32;
    uint32_t *t_u32_ptr;

    uint64_t data_u64;
    uint64_t *t_u64_ptr;


    // uint8_t non aligned access
    data_u8 = 0xab;
    t_u8_ptr = &(m_st.t_u8);   // t_u8_ptr is not 32bit aligned

    m_st.t_u8 = data_u8;       // Direct access works
    *t_u8_ptr = data_u8;       // Indirect access works


    // uint16_t non aligned access
    data_u16 = 0xabcd;
    t_u16_ptr = &(m_st.t_u16); // t_u16_ptr is not 32bit aligned

    m_st.t_u16 = data_u16;     // Direct access works
    *t_u16_ptr = data_u16;     // Indirect access works


    // uint32_t non aligned access
    data_u32 = 0xabcdabcd;
    t_u32_ptr = &(m_st.t_u32); // t_u32_ptr is not 32bit aligned

    m_st.t_u32 = data_u32;     // Direct access works
    *t_u32_ptr = data_u32;     // Indirect access works


    // uint64_t non aligned access
    data_u64 = 0xabcdabcdabcdabcd;
    t_u64_ptr = &(m_st.t_u64); // t_u64_ptr is not 32bit aligned.

    m_st.t_u64 = data_u64;     // Direct access works
    *t_u64_ptr = data_u64;     // Indirect access causes crash; 

Hi George,

Poking around, I've found the following in the compiler manual (SPNU151N  section 5.16.4)

"It is illegal to implicitly or explicitly cast the address of a packed struct member as a pointer to any non-packed type except an unsigned char. "

If I understand this right (and I'm not sure I am, because I don't think there is any type casting going on here), it means the following lines of my example are illegal.

t_u16_ptr = &(m_st.t_u16);  

t_u32_ptr = &(m_st.t_u32);

t_u64_ptr = &(m_st.t_u64);

Which is fine - but if it is illegal, should there be a warning or error????

Whether or not there is an explicit cast, there is a pointer type conversion in each of those assignments. The text in the manual is a little bit loose with the technical language; the crucial point is you can't access an object through a pointer to a differently-packed type unless one of the types is pointer to unsigned char.

Thank you George,

I've learnt a lot!
I didn't realise that "packed" is part of the type, and that hardware takes care of things up to 32bits.

Thanks for your time.

Cheers
Julian