"H.J. Lu" <hjl.to...@gmail.com> writes:
> Index: gcc/doc/extend.texi
> ===================================================================
> --- gcc/doc/extend.texi (revision 4884)
> +++ gcc/doc/extend.texi (working copy)
> @@ -3697,9 +3697,8 @@ that forces the union to be double-word
> 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 machine you are compiling for. For
> -example, you could write:
> +and use @code{ATTRIBUTE_ALIGNED_VALUE} for the target machine you are
> +compiling for. For example, you could write:
>
> @smallexample
> short array[3] __attribute__ ((aligned));
> @@ -3707,11 +3706,11 @@ short array[3] __attribute__ ((aligned))
>
> 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 which is ever used for any data
> -type on the target machine 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.
> +variable or field to @code{ATTRIBUTE_ALIGNED_VALUE}. Doing this can
> +often make copy operations more efficient, because the compiler can use
> +whatever instructions copy the biggest chunks of memory aligned at
> +...@code{attribute_aligned_value} when performing copies to or from the
> +variables or fields that you have aligned this way.
ATTRIBUTE_ALIGNED_VALUE is an internal compiler macro. extend.texi is
external user documentation. extend.texi should not documented the
attribute in terms of ATTRIBUTE_ALIGNED_VALUE.
> Index: gcc/testsuite/gcc.target/i386/pr38736-2.c
> ===================================================================
> --- gcc/testsuite/gcc.target/i386/pr38736-2.c (revision 0)
> +++ gcc/testsuite/gcc.target/i386/pr38736-2.c (revision 0)
> @@ -0,0 +1,19 @@
> +/* PR target/38736 */
> +/* { dg-do run } */
> +/* { dg-require-effective-target avx } */
> +/* { dg-options "-O2 -mavx" } */
> +
> +extern void abort (void);
> +
> +struct alignment_test_struct
> +{
> + char space[4] __attribute__((__aligned__));
> +};
> +
> +int
> +main ()
> +{
> + if (__alignof__(struct alignment_test_struct) != 16)
> + abort ();
> + return 0;
> +}
This test case seems to be asserting that attribute ((aligned)) should
always align to a 16-byte boundary on x86. It is not clear to me that
that should be the case. In fact, I tend to think that it should not
be the case.
It would be better to (somehow) have a multi-file test which checked
that attributed ((aligned)) has the same value with and without -mavx.
> +/* Alignment value for attribute ((aligned)). It is a constant
> + since it is the part of the ABI. */
> +#define ATTRIBUTE_ALIGNED_VALUE 128
Please add some comment here about the AVX issue.
Ian
