Forum Post: how to force double alignment to 4 bytes from gcc for ARM?

Hello,

I've run into a data alignment problem in my code running on the AM389x Sitara (ARM Cortex A8).  The code is compiled using the CodeSourcery gcc compiler.  

My problem is I have a structure that contains 13 int types followed by a double.  The double data in memory starts at the address immediately after the 13th int member.  I can see though that the code thinks the double starts at the address of the 13th int + 4 bytes (if I point to the double at the address the code tells me at less 4 bytes, it is printed correctly).  Alternately, if I add a dummy int member immediately before the double, the code prints the double correctly.

It looks like the processor aligns double on 4 byte boundaries (1 word), but the compiler thinks they are on 8 byte boundaries, and so assumes a 4 byte pad before the double after the 13 bytes.  As a solution, it seems the gcc option -mno-align-double would fix it, but the CodeSourcery gcc doesn't accept it (and it isn't listed in the CodeSourcery compiler manual under ARM options -- it is listed as an Intel 386 option).

Is there a way to make the compiler align doubles on 4 byte boundaries with ARM and this compiler?  Is there another way to fix this?  Inserting pads is not really a viable option because I have many structures like this and anybody could change one and ignore the need for the pad.

My data structure is shown below, followed by printfs of the start address of each structure member.  Also, __align_of__ (double) returns 8.

typedef struct input_timing_s
{
int chan;
int src_pwr_det;
int clk_det;
int de_det;
int sig_stable;
unsigned int time_locked;
int mode;
int hdcp_authenticated;
int hdcp_src_dev_auth_start;
int horiz_active;
int horiz_blank;
int vert_active;
int vert_blank;
double tmds_frequency;
int horiz_sync_polarity;
int vert_sync_polarity;
int interlace;
} input_timing_t;

addr of chan=0xbe9ca780
src_pwr_det=0xbe9ca784
clk_det=0xbe9ca788
de_det=0xbe9ca78c
sig_stable=0xbe9ca790
time_locked=0xbe9ca794
mode=0xbe9ca798
hdcp_authenticated=0xbe9ca79c
hdcp_src_dev_auth_start=0xbe9ca7a0
horiz_active=0xbe9ca7a4
horiz_blank=0xbe9ca7a8
vert_active=0xbe9ca7ac
vert_blank=0xbe9ca7b0
tmds_frequency=0xbe9ca7b8
horiz_sync_polarity=0xbe9ca7c0
vert_sync_polarity=0xbe9ca7c4
interlace=0xbe9ca7c8

Thanks,

Tim