While testing my improvements to detect mutually exclusive attribute specifications I came across another problem, this one specific to the _Alignas specifier (but it should also apply to attribute aligned. both on objects and functions). In 6.7.5, p7, C11 specifies the following two requirements on _Alignas: If the definition of an object has an alignment specifier, any other declaration of that object shall either specify equivalent alignment or have no alignment specifier. If the definition of an object does not have an alignment specifier, any other declaration of that object shall also have no alignment specifier. The test case below violates both of these requirements and so should be diagnosed but isn't. The problem seems to be (as in bug 81544 and some others) that the handle_aligned_attribute() function in c-family/c-attribs.c doesn't have access to the last declaration as it processes a new one. That GCC manages to do the reasonable thing despite it (i.e., use the most restrictive alignment) means that some other mechanism must detect and resolve the conflict, but without diagnosing it. $ cat b.c && gcc -O2 -S -Wall -Wextra -Wpedantic -o /dev/stdout b.c extern _Alignas (32) int a; _Alignas (8) int a = 32; // violates sentence 1 extern _Alignas (32) int b; extern _Alignas (16) int b; extern _Alignas (8) int b; int b = 32; // violates sentence 2 .file "b.c" .globl b .data .align 32 .type b, @object .size b, 4 b: .long 32 .globl a .align 32 .type a, @object .size a, 4 a: .long 32 .ident "GCC: (GNU) 8.0.0 20170727 (experimental)" .section .note.GNU-stack,"",@progbits
To be clear: that requirement is not a constraint, so no diagnostic is required. Diagnosis may make sense for _Alignas, but I don't think different choices of __attribute__ ((aligned)) should be diagnosed, as a matter of compatibility with existing code.
See also bug 81566 for a related problem with attribute aligned on function declarations.