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.

Reply via email to