https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Petro Karashchenko from comment #11)
> Sorry but based on
>
> @cindex @code{aligned} variable attribute
> @item aligned
> @itemx aligned (@var{alignment})
> The @code{aligned} attribute specifies a MINIMUM alignment for the variable
> or structure field, measured in bytes. When specified, @var{alignment} must
> be an integer constant power of 2. Specifying no @var{alignment} argument
> implies the maximum alignment for the target, which is often, but by no
> means always, 8 or 16 bytes.
>
> I do not see any statement saying that giving a lower alignment is invalid.
> I see "attribute specifies a MINIMUM alignment" so "int i
> __attribute__((aligned(1)));" specifies that between 1 and 4 the 1 should be
> chosen as a "MINIMUM".
>
> The statement "must be an integer constant power of 2" is also valid because
> 1 is a 0 power of 2. So no questions here.
>
> "Thus IMHO this bug is invalid." -- I do not see any strong argument on
> this. All prerequisites from a description are met, so this is a pure bug.
The testcase of the description is
typedef int __attribute__((vector_size(16))) v4si;
v4si a4 __attribute__((aligned(4)));
that creates a variable with minimum alignment 4 (as seen in the assembly
output). But you give the variable a type of 'v4si' which has larger
alignment and thus is in conflict with the alignment for the storage you
specified. That automatically runs into the standard mandated rule that
any access has to be aligned according to its type.
The expectation that accesses should be unaligned is wrong unless you
also use an unaligned type.
That GCC creates an object with the desired alignment isn't wrong - you told it
so.
As I said the conflict should probably be diagnosed as it results in unexpected
behavior.
