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 <quic_pzh...@quicinc.com>
---
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 ());
--
2.17.1
