On Thu, Jan 8, 2009 at 10:17 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Thu, Jan 8, 2009 at 12:40 PM, Ian Lance Taylor <i...@google.com> wrote: >> "H.J. Lu" <hjl.to...@gmail.com> writes: >> >>> We can solve it with >>> >>> 1. A target should define MALLOC_ABI_ALIGNMENT properly. >>> 2. g++ should issue an error when the default new operator >>> is used on a type whose alignment is greater than >>> MALLOC_ABI_ALIGNMENT. >>> 3. It is user's responsibility to provide a new operator to return >>> a properly aligned memory. >>> 4. g++ can assume memory return by the user-provided new >>> operator is properly aligned. >> >> Sounds good as far as it goes. How do we get there from here? What >> should the behaviour of __attribute__ ((aligned)) be? Should we add > > For 4.4, we can apply my patch: > > http://gcc.gnu.org/ml/gcc-patches/2009-01/msg00367.html > > and update document with > > As in the preceding examples, you can explicitly specify the alignment > (in bytes) that you wish the compiler to use for a given variable or > structure field. Alternatively, you can leave out the alignment factor > and just ask the compiler to align a variable or field to the maximum > useful alignment for the target ABI you are compiling for. For > example, you could write: > > @smallexample > short array[3] __attribute__ ((aligned)); > @end smallexample > > Whenever you leave out the alignment factor in an @code{aligned} attribute > specification, the compiler automatically sets the alignment for the declared > variable or field to the largest alignment for the target ABI you are > compiling for. Doing this can often make copy operations more efficient, > because the compiler can use whatever instructions copy the biggest > chunks of memory when performing copies to or from the variables or > fields that you have aligned this way.
I don't think we should encourage more uses of __attribute__((aligned)). Richard.
