> Pengxuan Zheng <[email protected]> writes:
> > There was a bug in aarch64_evpc_reencode which could leave zero_op0_p
> > and zero_op1_p of the struct "newd" uninitialized.
> > r16-701-gd77c3bc1c35e303 fixed the issue by zero initializing "newd."
> > This patch provides an alternative fix as suggested by Richard
> > Sandiford based on the fact that the zeroness is preserved by
> aarch64_evpc_reencode.
> >
> > gcc/ChangeLog:
> >
> > * config/aarch64/aarch64.cc (aarch64_evpc_reencode): Copy
> zero_op0_p and
> > zero_op1_p from d to newd.
> >
> > Signed-off-by: Pengxuan Zheng <[email protected]>
>
> OK, thanks.
>
> Richard
Thanks, pushed as r16-811-g84c6988c026114.
Pengxuan
>
> > ---
> > gcc/config/aarch64/aarch64.cc | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/gcc/config/aarch64/aarch64.cc
> > b/gcc/config/aarch64/aarch64.cc index 1da615c8955..2b837ec8e67
> 100644
> > --- a/gcc/config/aarch64/aarch64.cc
> > +++ b/gcc/config/aarch64/aarch64.cc
> > @@ -26327,7 +26327,7 @@ aarch64_evpc_trn (struct expand_vec_perm_d
> *d)
> > static bool aarch64_evpc_reencode (struct expand_vec_perm_d *d) {
> > - expand_vec_perm_d newd = {};
> > + expand_vec_perm_d newd;
> >
> > /* The subregs that we'd create are not supported for big-endian SVE;
> > see aarch64_modes_compatible_p for details. */ @@ -26353,6
> > +26353,8 @@ aarch64_evpc_reencode (struct expand_vec_perm_d *d)
> > newd.op1 = d->op1 ? gen_lowpart (new_mode, d->op1) : NULL;
> > newd.testing_p = d->testing_p;
> > newd.one_vector_p = d->one_vector_p;
> > + newd.zero_op0_p = d->zero_op0_p;
> > + newd.zero_op1_p = d->zero_op1_p;
> >
> > newd.perm.new_vector (newpermindices.encoding (),
> newd.one_vector_p ? 1 : 2,
> > newpermindices.nelts_per_input ());
