On Mon, Jun 10, 2013 at 11:44 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> On Mon, Jun 10, 2013 at 07:51:54AM -0700, Richard Henderson wrote:
>> 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.
>
> Ok, here is what I've committed to trunk (will wait for some time before
> backporting). As discussed with Honza on IRC, decl_binds_to_current_def_p
> will need further fixing, it does the wrong thing for extern int var
> __attribute__((visibility ("hidden"))) or hidden DECL_COMMON symbols.
>
> And, we don't have any feedback about SPE/E500 rs6000 - DATA_ALIGNMENT vs.
> DATA_ABI_ALIGNMENT yet.
SPE/e500 support was written by Aldy. He or someone from Freescale
needs to comment.
- David
