RE: [PATCH PR95523] aarch64:ICE in register_tuple_type,at config/aarch64/aarch64-sve-builtins.cc:3434
Zhanghaijian (A)
z.zhanghaijian@huawei.com
Thu Jun 11 01:12:32 GMT 2020
Thanks for viewing and pushing this.
Thanks,
Haijian Zhang
> -----Original Message-----
> From: Richard Sandiford [mailto:richard.sandiford@arm.com]
> Sent: Thursday, June 11, 2020 12:01 AM
> To: Zhanghaijian (A) <z.zhanghaijian@huawei.com>
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH PR95523] aarch64:ICE in register_tuple_type,at
> config/aarch64/aarch64-sve-builtins.cc:3434
>
> Hi,
>
> "Zhanghaijian (A)" <z.zhanghaijian@huawei.com> writes:
> > This is a simple fix for pr95523.
> > When registering the tuple type in register_tuple_type, the TYPE_ALIGN
> (tuple_type) will be changed by -fpack-struct=n.
> > We need to maintain natural alignment in handle_arm_sve_h.
> > Bootstrap and tested on aarch64 Linux platform. No new regression
> witnessed.
>
> Sorry for dropping the ball on the bugzilla PR and not replying to your comment
> there. For the record...
>
> IMO it's a misfeature that -fpack-struct=N and “#pragma pack (1)”
> override explicit alignments. E.g. it means that for:
>
> struct __attribute__((packed)) s1 { __attribute__((aligned(2))) int x; };
> #pragma pack (1)
> struct s2 { __attribute__((aligned(2))) int x; };
>
> s1 has alignment 2 but s2 has alignment 1. There's a comment about this in
> stor-layout.c:
>
> /* Should this be controlled by DECL_USER_ALIGN, too? */
> if (mfa != 0)
> SET_DECL_ALIGN (decl, MIN (DECL_ALIGN (decl), mfa));
>
> I think the condition probably should have checked DECL_USER_ALIGN.
>
> However, there's no telling whether anything now relies on the current
> behaviour, and since this bug is about internally-defined structures, it's
> probably not a good motivating example for changing the code above.
>
> Also, I agree the patch is a clean way of avoiding the problem, and is probably
> more robust than the DECL_USER_ALIGN thing would have been.
>
> Pushed to master, thanks.
>
> Richard
More information about the Gcc-patches
mailing list