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. > any new __attribute ((aligned (XXX))) options? > I don't think we need new __attribute ((aligned (XXX))) options. -- H.J.
