Weird structure alignment on GCC 4.2

Weird structure alignment on GCC 4.2

[andrew wiggin]

Hi All,

I tried to browse the mailing list about that, but there are so many
threads that I gave up, so I end up asking you the question:
What I need is that for obvious reasons 32 bits element are considered
as Words and aligned on 32bits addresses, 16bits elements are as
considered Half-Words and aligned on 16bits addresses and 8bits
elements are considered as Bytes and aligned on 8bits addresses which
was fine with all previous version of GCC I was using. I have defined
some structure like that:

struct _s1 {
    unsigned char e1;
    unsigned char e2;
};

struct _s2 {
    void e1;
    struct _s2 e2[2];
    void e3;
};


The result is that with no packing attribute, the line "struct _s2
e2[2];" will be interpreted as ".align 4 / .byte / .byte .align 4 /
.byte / .byte" however there is absolutely no reason why this
alignment in the middle of the structure happens. The problem when
using the "packed" attribute is that most of the 16bits elements will
be considered as 2 8bits elements and 32 bits elements will be
considered as 4 8bits elements which is absolutely not what I want as
these structures are mapped on internal registers that must be written
in an atomic instruction.

So the question is, what did I miss ? Is it the intended behavior for
GCC >= 4.2 or does a patch already exist for fixing that.

Thanks a lot,
--
ender

Re: Weird structure alignment on GCC 4.2

[Ian Lance Taylor]

"andrew wiggin" <end3er@gmail.com> writes:

> struct _s1 {
>     unsigned char e1;
>     unsigned char e2;
> };
>
> struct _s2 {
>     void e1;
>     struct _s2 e2[2];
>     void e3;
> };

This code doesn't compile.  For discussing issues like this it helps
to see the exact code.

> The result is that with no packing attribute, the line "struct _s2
> e2[2];" will be interpreted as ".align 4 / .byte / .byte .align 4 /
> .byte / .byte" however there is absolutely no reason why this
> alignment in the middle of the structure happens. The problem when
> using the "packed" attribute is that most of the 16bits elements will
> be considered as 2 8bits elements and 32 bits elements will be
> considered as 4 8bits elements which is absolutely not what I want as
> these structures are mapped on internal registers that must be written
> in an atomic instruction.
>
> So the question is, what did I miss ? Is it the intended behavior for
> GCC >= 4.2 or does a patch already exist for fixing that.

Struct layout is specified by the processor ABI, so that different
compilers for the same processor can interoperate.  When I compile
this code:

struct _s1 {
    unsigned char e1;
    unsigned char e2;
};

struct _s2 {
    void *e1;
    struct _s1 e2[2];
    void *e3;
};

struct _s2 v = { 0, { { 1, 2 }, { 3, 4 } } , 0 };

for the x86, then I do not see the alignment you mention.  So you need
to tell us what target you are using.

Ian

Re: Weird structure alignment on GCC 4.2

[andrew wiggin]

Sorry for having replied just to you. I am not that used with mailing lists.

Actually, I have tried different solutions, including the flag you
proposed, I didn't kept it as I identified some side effect I thought
were linked to that option. However it was linked to some bad
structure declaration in some other part of the code...

Finally, after testing on some "sample" code it seems that it behaves
exactly like what I was asking for. Thanks a lot for your help !

-- 
ender


On Mon, Sep 29, 2008 at 7:49 PM, Ian Lance Taylor <iant@google.com> wrote:
> "andrew wiggin" <end3er@gmail.com> writes:
>
>> Thanks for your reply. I missed the * after the void as originally all
>> the types I use are tagged like u32 / s32 / u16 etc...
>>
>> So, my Target is ARM9(26EJ-S) in big endian mode. I used the t-arm-elf
>>From gcc when compiling, I just removed the compilation for little
>> endian.
>> the structure I obtain is: {e1, {{e2[0].e1, e2[0].e2}, {X,X}},
>> {{e2[1].e1,e2[1].e2}, {X, X}}, e3}
>
> Please reply to the mailing list, not just to me.  Thanks.
>
> For ARM, see the -mstructure-size-boundary option in the
> documentation.
>
> Ian
>