Compiler optimization can sometimes cause unpredictable or even incorrect behavior. Below is a blob of C code for the TI MSP430 compiler that exemplifies at le

Compiler optimization can sometimes cause unpredictable or even incorrect behavior. Below is a blob of C code for the TI MSP430 compiler that exemplifies at least one of TI's optimization bugs: // Define Common Communications Frame typedef volatile union commFrameType { struct { unsigned SyncHeader:16; unsigned MessageID:8; unsigned short MessageData[msgDataSize]; // ID-unique data unsigned CRC:8; // LSB of CCITT-16 for above data } __attribute__ ((packed)) Frame; unsigned char b[16]; // Accessible as raw bytes as well unsigned short w[8]; // Accessible as raw words as well unsigned long l[4]; // Accessible as raw long words as well } __attribute__ ((packed)) CommFrame; static CommFrame IpcMessage = { FRAME_SYNC_R, IpcBlankMessage }; // If frame was accepted into TX queue, prepare next frame for transmission // IpcMessage.Frame.MessageID++; // Bump up to next message type // IpcMessage.Frame.MessageID += 1; // The above two lines that are commented out cause a bizzare linker error if either are used instead of the line below. IpcMessage.Frame.MessageID = IpcMessage.Frame.MessageID + 1; // Bump up to next message type The MSP-430 is a 16-bit microcontroller and the packed CommFrame structure has Frame.MessageID on an odd-byte boundary. Some processors might raise a SIGBUS, but TI says that it's okay to access a byte on an odd address boundary. It's pretty silly that i++; and i+=1; don't work, but i=i+1; is just fine.