The real question was in my other post within the same thread. I
summarize it here:
is struct S { } __attribute__ ((aligned (16))); supposed to give me
16 byte aligned allocation when object of type S are allocated:
1) globally
2) automatically on the stack
3) dynamically on the heap ?
The answers I got up to now are:
- maybe in 1) and 2) but depends on the stack alignment guarantees
of the ABI
- yes for 1) [modulo linker limitations]. Even though the
documentation doesn't says so the aligned attribute was only intended
for
global allocations.
- in general no, but depends on CPU/OS
I tend now to believe the right answer is the second one [and the
documentation should be fixed accordingly], but I haven't checked
the source code for GCC. Still, I've posted a small example in my
original post where GCC seems to obey the alignment for stack
allocated objects (and my larger example show GCC obeying the
alignemnt for heap allocated objects). But the example is really not
conclusive (there're also aligned global allocations that might
change the stack position).
My last post mentioned __alignof(long double) just to show that on
linux x86_64 GCC has the capability of enforcing 16 byte alignment
for global/heap/stack allocation (either that or __alignof would have
a very surprising semantics [btw, __alignof
(Struct_With_16_Byte_Aligned_Attribute) is 16 on my machine). This
should rule out the possibility of linker limitations or other
machine specific limitations preventing GCC from giving 16 bytes
alignments to objects and makes likely that the situation is either:
a) GCC only tries 1) [global allocation] and the documentation
should, imo, be clarified (both for the aligned attribute and the
behaviour of __alignof).
b) GCC tries 1), 2) and 3) and then I have at least one case in
which fails that I have to turn into a shorter example to submit as a
bug report
For the moment I haven't looked into the source code for GCC for
looking at what happens with the aligned attribute processing
Maurizio Vitale
On Dec 22, 2006, at 7:02 AM, Andrew Haley wrote:
(top-posting fixed)
Maurizio Vitale writes:
On Dec 21, 2006, at 4:23 PM, Tim Prince wrote:
Maurizio Vitale wrote:
Thanks. Now to add to my confusion, on my system __alignof(long
double) returns 16, which I presume means that all allocation,
static, dynamic and automatic for long double objects are 16 byte
aligned.
This is a reasonable choice, that long doubles would be aligned for
good performance, unless the alignment is over-ridden by a packed
or reduced alignment specification.
It is certainly reasonable, but if it is true it means that the
compiler is capable on linux, x86_64 to impose a 16 byte alignment on
some object for all type of allocations. Then I would expect an
__attribute__ ((aligned (16)) for a user defined type to be obeyed as
well.
I haven't tested whether long doubles are actually allocated on 16
byte boundaries in all case (global, auto and dynamic), mainly
because the tests would be inconclusive, unless you see an alignment
< 16.
I just mentioned the data point to see if it did say anything to GCC
developers.
Well, we don't know what question you're trying to ask. If you can be
specific, we'll give you an answer.
Andrew.
