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