https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127632
--- Comment #3 from Avinash Jayakar <avinashd at gcc dot gnu.org> --- I had used the below for bootstrap and regtesting the patch r17-3175-gc31b7a09eea3c3, and it worked fine, configure --target=powerpc64le-linux --host=powerpc64le-linux --build=powerpc64le-linux --enable-languages=c,c++,fortran,objc,obj-c++ --enable-gnu-indirect-function --with-cpu=power8 --with-long-double-128 --with-cpu=power10 --enable-checking=yes,extra,rtl --disable-libsanitizer --disable-alsa therefore did not notice this problem. Andreas did report this earlier in the patch reply: https://gcc.gnu.org/pipermail/gcc-patches/2026-September/729670.html But I assumed it only happened when -Werror=maybe-uninitialized was explicit (This case is false positive since we initialize it in first iteration and access of size happens only in second iteration). Apologies for not looking into it earlier. The variable should be safe to be initialized to 0, since the check size != tree_to_uhwi (size_tree) happens second iteration onward where size is already initialized. diff --git a/gcc/config/rs6000/rs6000-c.cc b/gcc/config/rs6000/rs6000-c.cc index ecc3ff4e24e..f51593e0455 100644 --- a/gcc/config/rs6000/rs6000-c.cc +++ b/gcc/config/rs6000/rs6000-c.cc @@ -1734,7 +1734,7 @@ altivec_resolve_overloaded_builtin (location_t loc, tree fndecl, error_at (loc, "%qE requires 6 arguments", fndecl); return error_mark_node; } - unsigned HOST_WIDE_INT size; + unsigned HOST_WIDE_INT size = 0; for (int i=0; i<3; i++) { /* Get the first argument to determine the actual type. */ tree arg0 = (*arglist)[i]; this should fix the issue. I will bootstrap and regtest it properly and submit the patch. Thanks.
