Re: aligned attribute

[Maurizio Vitale <maurizio dot vitale at polymath-solutions dot com>]

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.