On Thu, Jan 8, 2009 at 5:22 PM, Ian Lance Taylor <i...@google.com> wrote: > "H.J. Lu" <hjl.to...@gmail.com> writes: > >>> 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. > > The compiler knows about malloc and new. It should presumably assume > that memory allocated by those operations should have some alignment. > One might naïvely expect that the alignment of malloc would in fact by > MALLOC_ABI_ALIGNMENT. Perhaps MALLOC_ABI_ALIGNMENT is simply > misnamed, or perhaps attribute((aligned)) should align to some other > value. >
We can't change the value of attribute((aligned)) now since it is used in public header. >>>>> 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. > > There are many ways to align data without exposing it in the > ABI--e.g., the alignment of a global array is not part of the ABI, in > that nothing breaks if the alignment is increased. Also, there are > many programs which simply don't care about an external ABI. > You can just use a value like __attribute ((aligned (8))) or some value suitable for the variable type. It is as good as any value we can use with __attribute__ ((aligned(max))) today since whatever we choose now may not be appropriate later. If __attribute ((aligned (8))) is used on a variable, compiler is free to use larger alignment if needed. We can't increase it only when it is used on a struct field. -- H.J.
