> Pengxuan Zheng <quic_pzh...@quicinc.com> writes:
> > Some fields (e.g., zero_op0_p and zero_op1_p) of the struct "newd" may
> > be left uninitialized in aarch64_evpc_reencode. This can cause reading
> > of uninitialized data. I found this oversight when testing my patches
> > on and/fmov optimizations. This patch fixes the bug by zero initializing
the
> struct.
> >
> > Pushed as obvious after bootstrap/test on aarch64-linux-gnu.
> >
> > gcc/ChangeLog:
> >
> > * config/aarch64/aarch64.cc (aarch64_evpc_reencode): Zero initialize
> > newd.
> > ---
> > gcc/config/aarch64/aarch64.cc | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/gcc/config/aarch64/aarch64.cc
> > b/gcc/config/aarch64/aarch64.cc index 2371541ef1b..c067e099d83
> 100644
> > --- a/gcc/config/aarch64/aarch64.cc
> > +++ b/gcc/config/aarch64/aarch64.cc
> > @@ -26246,7 +26246,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 = {};
>
> Wouldn't it be better to initialise the fields to useful values instead?
> Zeroness is carried over by reencoding, so I would expect:
>
> newd.zero_op0_p = d->zero_op0_p;
> newd.zero_op1_p = d->zero_op1_p;
>
> instead of the above.
Thanks for pointing this out, Richard! Here's the alternative fix you
suggested.
https://gcc.gnu.org/pipermail/gcc-patches/2025-May/684317.html
Please let me know if you have any other comments.
Thanks,
Pengxuan
>
> Thanks,
> Richard
>
> >
> > /* The subregs that we'd create are not supported for big-endian SVE;
> > see aarch64_modes_compatible_p for details. */
