[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|msebor at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #8 from Martin Sebor --- I'm not working on this anymore.
[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914
--- Comment #7 from Eric Gallager ---
(In reply to Martin Sebor from comment #5)
> (In reply to Paul Eggert from comment #4)
> > Here, GCC says the alignment of 'b' is 1, not 8. What happened to the
> > attribute?
>
> GCC silently drops it, without validating it. For instance, this is
> accepted as well:
>
> struct s { char mem; };
>
> struct __attribute__ ((foobar))
> s b;
>
> I view it as a bug. At a minimum, GCC should point out that it's ignoring
> the attribute like other compilers do, such as Clang:
>
> warning: unknown attribute 'foobar' ignored [-Wunknown-attributes]
>
> I happened to notice this bug while testing a fix for pr84108. It seems
> that a simple fix is fairly straightforward so hopefully Richard won't be
> offended if I reopen this bug, assign it to myself, and submit my patch in
> stage 1 of GCC 9.
It's stage 1 of gcc 9 now.
[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914 --- Comment #6 from Martin Sebor --- Created attachment 43330 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43330&action=edit Patch tested on x86_64-linux. GCC 9 patch regression-tested on x86_64-linux.
[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Status|RESOLVED|ASSIGNED
Last reconfirmed||2018-02-02
CC||msebor at gcc dot gnu.org
Resolution|INVALID |---
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #5 from Martin Sebor ---
(In reply to Paul Eggert from comment #4)
> Here, GCC says the alignment of 'b' is 1, not 8. What happened to the
> attribute?
GCC silently drops it, without validating it. For instance, this is accepted
as well:
struct s { char mem; };
struct __attribute__ ((foobar))
s b;
I view it as a bug. At a minimum, GCC should point out that it's ignoring the
attribute like other compilers do, such as Clang:
warning: unknown attribute 'foobar' ignored [-Wunknown-attributes]
I happened to notice this bug while testing a fix for pr84108. It seems that a
simple fix is fairly straightforward so hopefully Richard won't be offended if
I reopen this bug, assign it to myself, and submit my patch in stage 1 of GCC
9.
[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914
--- Comment #4 from Paul Eggert ---
(In reply to Richard Biener from comment #2)
> You are not using aligned on a 'struct or struct member' but on the variable
> in all but (b).
If that's the intent, then GCC is mishandling the first example I gave in
comment #0:
struct s { char mem; };
__attribute__ ((aligned (8))) struct s a;
struct __attribute__ ((aligned (8))) s b;
struct s __attribute__ ((aligned (8))) c;
struct s d __attribute__ ((aligned (8)));
Here, GCC says the alignment of 'b' is 1, not 8. What happened to the
attribute?
Later discussion in https://bugs.gnu.org/29183 has revealed that this first
example is also relevant to Emacs, and that Emacs crashes due to problems in
this area as well.
In summary there seems to be no straightforward way in GNU C to get what Emacs
wants, which is to say, "I want V's address to be a multiple of max(8, (natural
alignment for V))." I think I'll look into fixing Emacs to use unions instead.
Could you please fix the GCC documentation to clarify what's going on here? I
don't understand it myself, so I'm afraid any doc patch that I propose wouldc
be wrong.
[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment #3 from Eric Gallager ---
(In reply to Richard Biener from comment #2)
> (In reply to Paul Eggert from comment #1)
> > (In reply to Paul Eggert from comment #0)
> >
> > Sorry, but my example in comment #0 (although it illustrates a bug) doesn't
> > illustrate the bug that crashed GCC. Here's a better example:
> >
> > struct t { long mem; };
> > __attribute__ ((aligned (2))) struct t a;
> > struct __attribute__ ((aligned (2))) t b;
> > struct t __attribute__ ((aligned (2))) c;
> > struct t d __attribute__ ((aligned (2)));
> >
> > This compiles into:
> >
> > .comm a,8,2
> > .comm b,8,8
> > .comm c,8,2
> > .comm d,8,2
> >
> > Here, only 'b' is aligned correctly. The variables a, c, and d have an
> > alignment of only 2, but they should have an alignment of 8 because
> > __attribute__ ((aligned (8))) is documented to never decrease the alignment
> > of a structure, only to increase it. The GCC 7.2 documentation
> > > html> says, "When used on a struct, or struct member, the 'aligned'
> > attribute can only increase the alignment; in order to decrease it, the
> > 'packed' attribute must be specified as well."
>
> I think this applies to types but not to variables. IIRC there's no packed
> attribute for variables:
>
> int a __attribute__((aligned(2),packed));
> > gcc-7 -S t.c
> t.c:1:1: warning: ‘packed’ attribute ignored [-Wattributes]
> int a __attribute__((aligned(2),packed));
> ^~~
>
> so yes, for type definitions you should need packed to decrease alignment
> but for variable declarations aligned is taken literally.
>
> You are not using aligned on a 'struct or struct member' but on the variable
> in all but (b).
You'd still think there'd be a diagnostic from -Wattributes for the aligned
attribute, too, not just the packed one...
[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #2 from Richard Biener ---
(In reply to Paul Eggert from comment #1)
> (In reply to Paul Eggert from comment #0)
>
> Sorry, but my example in comment #0 (although it illustrates a bug) doesn't
> illustrate the bug that crashed GCC. Here's a better example:
>
> struct t { long mem; };
> __attribute__ ((aligned (2))) struct t a;
> struct __attribute__ ((aligned (2))) t b;
> struct t __attribute__ ((aligned (2))) c;
> struct t d __attribute__ ((aligned (2)));
>
> This compiles into:
>
> .comm a,8,2
> .comm b,8,8
> .comm c,8,2
> .comm d,8,2
>
> Here, only 'b' is aligned correctly. The variables a, c, and d have an
> alignment of only 2, but they should have an alignment of 8 because
> __attribute__ ((aligned (8))) is documented to never decrease the alignment
> of a structure, only to increase it. The GCC 7.2 documentation
> html> says, "When used on a struct, or struct member, the 'aligned'
> attribute can only increase the alignment; in order to decrease it, the
> 'packed' attribute must be specified as well."
I think this applies to types but not to variables. IIRC there's no packed
attribute for variables:
int a __attribute__((aligned(2),packed));
> gcc-7 -S t.c
t.c:1:1: warning: ‘packed’ attribute ignored [-Wattributes]
int a __attribute__((aligned(2),packed));
^~~
so yes, for type definitions you should need packed to decrease alignment
but for variable declarations aligned is taken literally.
You are not using aligned on a 'struct or struct member' but on the variable
in all but (b).
[Bug c/82914] 'struct __attribute__ ((aligned (N))) s' ignores 'aligned' attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82914
--- Comment #1 from Paul Eggert ---
(In reply to Paul Eggert from comment #0)
Sorry, but my example in comment #0 (although it illustrates a bug) doesn't
illustrate the bug that crashed GCC. Here's a better example:
struct t { long mem; };
__attribute__ ((aligned (2))) struct t a;
struct __attribute__ ((aligned (2))) t b;
struct t __attribute__ ((aligned (2))) c;
struct t d __attribute__ ((aligned (2)));
This compiles into:
.comm a,8,2
.comm b,8,8
.comm c,8,2
.comm d,8,2
Here, only 'b' is aligned correctly. The variables a, c, and d have an
alignment of only 2, but they should have an alignment of 8 because
__attribute__ ((aligned (8))) is documented to never decrease the alignment of
a structure, only to increase it. The GCC 7.2 documentation
says, "When used on a struct, or struct member, the 'aligned' attribute can
only increase the alignment; in order to decrease it, the 'packed' attribute
must be specified as well."
