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,
Richard
>
> /* The subregs that we'd create are not supported for big-endian SVE;
> see aarch64_modes_compatible_p for details. */
