https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94338
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to huaixin chang from comment #7) > (In reply to Martin Sebor from comment #4) > > Sounds like there's agreement that the code should at least get a warning > > then, so confirmed. > > > > The attribute aligned section of the manual describing the variable > > attribute says: > > > > When used on a struct, or struct member, the aligned attribute can only > > increase the alignment... > > > > It's not clear whether struct here refers to a type or a variable (I'm > > guessing it's former but it's in the Common Variable Attribute section so it > > could easily be read as the latter). Either way, reducing the alignment of > > an object whose members explicitly ask for stricter alignment seems like a > > dangerous thing to do without a warning. > > > > I'll see if I can do this for GCC 11. > > It seems that the compiler thinks A.a is already aligned to 128-byte. > Because as I print alignof(A.a) and alignof(A.b) with the same definition, > they are 128. > > $./align > address of A 0x42003c > alignof A 4 > address of A.a 0x42003c > alignof A.a 128 > address of A.b 0x4200bc > alignof A.b 128 > > Is it in your consideration to actually align A.a to 128-byte boundary? I think there are only two reasonable actions. a) warn but otherwise change nothing b) reject the case similar to _Alignof ignoring the user specification as appearantly is done for the typedef and decl annotation isn't something we can do because it may have ABI impacts. That is, we need to make sure to not change layout & alignment of structures with such embedded objects. I'd lean towards b) here because as you show the actual behavior is broken. When you for example exchange 'long' with v4si typedefed as typedef int v4si __attribute__((vector_size(16))), do you then get aligned movaps when the actual structure is unaligned?
