https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88085
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
The implementation issue is that
extern int var __attribute__((aligned(1)));
has DECL_ALIGN of 8 but the type still has alignment of 32, so when you
take the address and dereference it you'll get a ref with 32 bit alignment.
For aligned attributes that increase alignment that's not a correctness issue
but for aligned attributes decreasing alignment it becomes a problem.
If we want to make the above work reliably we have to arrange for the
type of 'var' to be adjusted by the aligned attribute on the decl. But
IMHO diagnosing alignment decreasing attributes on decls would be
appropriate. The docs clearly say (emphasis mine):
@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.
so giving a larger alignment is valid.
Likewise for
extern int i __attribute__((aligned(1)));
the alignment of 'i' is known to be at least 1 from the attribute but
we also know that 'int' is aligned to 4 and thus can use that larger alignment.
Thus IMHO this bug is invalid. You have to reduce the alignment of the type
which is another alignment constraint seen by the compiler.
