Re: PATCH: PR target/38736: [4.4 Regression] -mavx can change the ABI via BIGGEST_ALIGNMENT

[Jakub Jelinek <jakub at redhat dot com>]

On Wed, Jan 07, 2009 at 11:59:14AM -0800, Ian Lance Taylor wrote:
> How about something like this for the second paragraph?  Other
> opinions welcome.
> 
>     When you leave out the alignment factor in an @code{aligned}
>     attribute specification, the compiler sets the alignment for the
>     variable or field to the largest useful alignment on the target
>     machine for which you are compiling.  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.
> 
>     When new instructions are added to a processor, they may cause the
>     largest useful alignment to increase.  A compiled library should
>     not rely on the precise effect of the @code{aligned} attribute
>     with no alignment factor remaining the same across different
>     compiler versions.  For example, if you expect to distribute a
>     binary version of a library which will be linked with code
>     compiled with future versions of GCC, be careful about putting
>     something like this in a header file for users of the library:
> 
>     @smallexample
>     struct s { char a; char buf[64] __attribute__ ((aligned)); };
>     extern void f(struct s*);
>     @end smallexample
> 
>     The precise offset of the field @code{buf} may change in different
>     compiler versions.

That doesn't reflect what the patch does for i386 (where it doesn't
set the default alignment to the largest useful alignment, but to the
4.3 and older default for compatibility) and I think it would be a very bad
idea to change it between compiler versions, that would make the aligned
attribute quite useless.  glibc uses it in its exported headers, so does
libstdc++ and so does unwind.h.

	Jakub