On Fri, 14 Jun 2024, Richard Biener wrote: > > I hope you'll find this all useful. As it happens I don't need to verify > > my needs with a RISC-V target anymore, so I'm leaving it all up to you now > > as I need to switch back to Alpha, which has been my actual objective, and > > these rebuilds have taken a lot of my attention already. > > I'm including > > @@ -2148,15 +2148,17 @@ get_group_load_store_type (vec_info *vinfo, > stmt_vec_info stmt_info, > ... > if (!nunits.is_constant (&cnunits) > || !LOOP_VINFO_VECT_FACTOR (loop_vinfo).is_constant (&cvf) > - || ((cremain = remain.to_constant (), true) > + || (((cremain = group_size * cvf - gap % cnunits), true) > && ((cpart_size = (1 << ceil_log2 (cremain))) != > cnunits) > > in a patch I'm testing that should eventually fix the above bogus diagnostic.
Thank you. I can see your fix went in with e575b5c56137 and I can confirm that with: <https://patchwork.sourceware.org/project/gcc/patch/20240612232026.41780-1-patr...@rivosinc.com/> applied (and its patched-autoconf artefacts removed) `riscv64-linux-gnu' target now succesfully builds for me as at 1bb2535c7cb2. Maciej
