https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116357
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 24 Jan 2025, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116357 > > --- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > So, shall we go for > --- gcc/c/c-decl.cc.jj 2025-01-21 09:13:54.523510241 +0100 > +++ gcc/c/c-decl.cc 2025-01-24 15:31:46.698725165 +0100 > @@ -7058,7 +7058,7 @@ grokdeclarator (const struct c_declarato > && TYPE_QUALS (element_type)) > { > orig_qual_type = type; > - type = TYPE_MAIN_VARIANT (type); > + type = build_qualified_type (type, TYPE_UNQUALIFIED); > } > type_quals = ((constp ? TYPE_QUAL_CONST : 0) > | (restrictp ? TYPE_QUAL_RESTRICT : 0) > > ? That looks sensible. Note I wonder where the aligned() was put back, maybe that simply needs to happen earlier? I think we also want a testcase that on i?86 for example properly aligns elements of typedef double adouble __attribute__((aligned(8))); struct X { int n; adouble x[1024]; }; not sure if there's a more commonly under-aligned base type to check this with. An aggregate would of course work as well but code paths might be subtly different.