On 06/07/2013 02:14 PM, Jakub Jelinek wrote: >> > When the linker merges common blocks, it chooses both maximum size and >> > maximum >> > alignment. Thus for any common block for which we can prove the block must >> > reside in the module (any executable, or hidden common in shared object), >> > we >> > can go ahead and use the increased alignment. > But consider say: > one TU: > struct S { char buf[15]; } s __attribute__((aligned (32))); > > another TU: > char c = 7; > struct S { char buf[15]; } s = { { 1, 2 } }; > char d = 8; > int main () { return 0; } > > (the aligned(32) is there just to simulate the DATA_ALIGNMENT optimization > increase). Linker warns about this (thus the question is if we want to > increase the alignment for optimization on commons at all) and doesn't align > it. >
Oh, right. I hadn't considered commons unifying with non-common variables, and the failure of commoning in that case. I'd mostly been thinking of uninitialized Fortran-like common blocks, where it is more common for the blocks to have nothing in common but the name. r~