Bug 1937076
| Summary: | New compile error on gcc 11 | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ferry Huberts <mailings> |
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 34 | CC: | aoliva, dmalcolm, fweimer, jakub, jwakely, law, mpolacek, msebor, nickc, rebus, sipoyare |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2021-03-09 19:34:54 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Ferry Huberts
2021-03-09 18:34:43 UTC
Probably caused by <https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=50bc94898fac1bd9cc1dabf227208fb5d369c4c4>. May be a package bug. That is a package bug.
Let's look at simple example:
__attribute__((aligned (64))) typedef struct foo { char a; } foo;
__attribute__((aligned (64))) typedef struct bar { char a[72]; } bar;
int c[] = { sizeof (foo), __alignof (foo), sizeof (struct foo), __alignof (struct foo), sizeof (bar), __alignof (bar), sizeof (struct bar), __alignof (struct bar) };
foo a[2];
bar b[2];
GCC has been rejecting forming an array of foo from ~ GCC 4.0 from early 2006, but is rejecting the latter only since GCC 11.
Both have the same problem though, that those typedefs define overaligned types where the size of those types
(which is necessarily equal to the size of the corresponding struct) is not an integral multiple of the alignment.
When you construct an array of such objects, you are asking for something impossible, while the first array element
perhaps can satisfy the alignment by having the whole declaration aligned that way, the second element which must immediately
follow the first element can't satisfy that alignment.
When it hasn't been rejected, if it "worked", it was by pure luck, the restrictions have been added because when not so lucky
code accessing such array elements didn't work at all.
If you comment out the a/b array definitions, you can see that the c array contains
1, 64, 1, 1, 72, 64, 72, 1.
The question is what exactly you want to achieve.
One possibility is you want already the structs to be aligned that way, then the fix is to put the attribute to the right spot.
E.g.
typedef struct __attribute__((aligned (64))) foo { char a; } foo;
typedef struct __attribute__((aligned (64))) bar { char a[72]; } bar;
will do that. c array will then be:
64, 64, 64, 64, 128, 64, 128, 64
and the testcase will compile, you can form such arrays just fine because the size is integral multiple of the alignment.
Or you shouldn't create arrays of foo and bar, but instead of struct foo and struct bar which have the normal ABI alignment requirements.
And if you want to ensure particular alignment of the start of those arrays, do:
typedef struct foo foo2[2] __attribute__((aligned (64)));
typedef struct bar bar2[2] __attribute__((aligned (64)));
foo2 a;
bar2 b;
etc.
Thanks for the quick responses, and very good explanation! Thank you |