On Thu, Jan 8, 2009 at 3:35 PM, Ian Lance Taylor <i...@google.com> wrote: > "H.J. Lu" <hjl.to...@gmail.com> writes: > >> 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. > > Shouldn't the docs say something about memory allocation? As in, > malloc should return memory aligned to that boundary? > > For that matter, don't we have a problem on x86 GNU/Linux, where > malloc returns an 8-byte alignment but attribute((aligned)) is a 16 > byte alignment?
I don't think it is the same as MALLOC_ABI_ALIGNMENT. attribute((aligned)) is something determined by compiler, which used to be a constant. > >>> any new __attribute ((aligned (XXX))) options? >>> >> >> I don't think we need new __attribute ((aligned (XXX))) options. > > Are we sure we don't need __attribute__ ((aligned(max)))? > I don't see how it can be used safely without breaking ABI. -- H.J.
