https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95523

rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #3 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 
---
(In reply to z.zhanghaij...@huawei.com from comment #2)
> (In reply to rsand...@gcc.gnu.org from comment #1)
> > The reason for the assert is that the alignment is part of the
> > ABI of the types and is relied on when using LDR and STR for
> > some moves.  Even though -fpack-struct=N changes the ABI in general,
> > I don't think it should change it in this particular case.
> > 
> > I have to wonder why GCC even has -fpack-struct= though.  Do you have
> > a specific need for it, or was this caught by option coverage testing?
> > 
> > If there is no specific need, I'd be tempted to make -fpack-struct
> > unsupported for AArch64.  I think there are so many other things
> > that could go wrong if it is used.
> 
> We use the option in some projects. If this option is not supported, the
> impact is relatively large.

Ah, OK.  If it's an issue that affects real use-cases then
let's make it work.

> I think it can make the error reporting more
> friendly, so that this option can still be used normally without sve.
> 
> like:
> diff --git a/gcc/config/aarch64/aarch64-sve-builtins.cc
> b/gcc/config/aarch64/aarch64-sve-builtins.cc
> index bdb04e8170d..e93e766aba6 100644
> --- a/gcc/config/aarch64/aarch64-sve-builtins.cc
> +++ b/gcc/config/aarch64/aarch64-sve-builtins.cc
> @@ -3504,6 +3504,12 @@ handle_arm_sve_h ()
>        return;
>      }
> 
> +  if (maximum_field_alignment)
> +    {
> +      error ("SVE is incompatible with the use of %qs or %qs",
> "-fpack-struct", "#pragma pack");
> +      return;
> +    }
> +
>    sve_switcher sve;
> 
>    /* Define the vector and tuple types.  */
> 
> Any suggestions?

Could you try setting DECL_USER_ALIGN on the FIELD_DECL?
that should (hopefully) force the field to keep its
natural alignment.

Reply via email to